AFAIK, an explicit rebase is required. On Saturday 23 July 2016, Pranith Kumar Karampuri <pkara...@redhat.com> wrote:
> > > On Sat, Jul 23, 2016 at 10:17 AM, Nithya Balachandran <nbala...@redhat.com > <javascript:_e(%7B%7D,'cvml','nbala...@redhat.com');>> wrote: > >> >> >> On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran <nbala...@redhat.com >> <javascript:_e(%7B%7D,'cvml','nbala...@redhat.com');>> wrote: >> >>> >>> >>> On Fri, Jul 22, 2016 at 9:07 PM, Pranith Kumar Karampuri < >>> pkara...@redhat.com >>> <javascript:_e(%7B%7D,'cvml','pkara...@redhat.com');>> wrote: >>> >>>> >>>> >>>> On Fri, Jul 22, 2016 at 8:12 PM, Pranith Kumar Karampuri < >>>> pkara...@redhat.com >>>> <javascript:_e(%7B%7D,'cvml','pkara...@redhat.com');>> wrote: >>>> >>>>> I am playing with the following diff, let me see. >>>>> >>>>> diff --git a/tests/volume.rc b/tests/volume.rc >>>>> index 331a802..b288508 100644 >>>>> --- a/tests/volume.rc >>>>> +++ b/tests/volume.rc >>>>> @@ -579,7 +579,9 @@ function num_graphs >>>>> function get_aux() >>>>> { >>>>> ##Check if a auxiliary mount is there >>>>> -df -h 2>&1 | sed 's#/build/install##' | grep -e >>>>> "[[:space:]]/run/gluster/${V0}$" -e "[[:space:]]/var/run/gluster/${V0}$" - >>>>> +local rundir=$(gluster --print-statedumpdir) >>>>> +local pid=$(cat ${rundir}/${V0}.pid) >>>>> +pidof glusterfs 2>&1 | grep -w $pid >>>>> >>>>> if [ $? -eq 0 ] >>>>> then >>>>> >>>> >>>> Based on what I saw in code, this seems to get the job done. Comments >>>> welcome: >>>> http://review.gluster.org/14988 >>>> >>>> >>> Nice work Pranith :) >>> All, once this is backported to release-3.7, any patches on release-3.7 >>> patches will need to be rebased so they will pass the NetBSD regression. >>> >> >> I am suddenly confused about this - will the patches need to be rebased >> or with the next run automatically include the changes once Pranith's fix >> is merged? >> > > May be someone more knowledgeable about this should confirm this, but at > least from the build-log, I don't see any rebase command being executed > with origin/master: > > *04:07:36* Triggered by Gerrit: http://review.gluster.org/13762*04:07:36* > Building remotely on slave26.cloud.gluster.org > <https://build.gluster.org/computer/slave26.cloud.gluster.org> (smoke_tests > rackspace_regression_2gb glusterfs-devrpms) in workspace > /home/jenkins/root/workspace/rackspace-regression-2GB-triggered*04:07:36* > > git rev-parse --is-inside-work-tree # timeout=10*04:07:36* Fetching changes > from the remote Git repository*04:07:36* > git config remote.origin.url > git://review.gluster.org/glusterfs.git # timeout=10*04:07:36* Fetching > upstream changes from git://review.gluster.org/glusterfs.git*04:07:36* > git > --version # timeout=10*04:07:36* > git -c core.askpass=true fetch --tags > --progress git://review.gluster.org/glusterfs.git > refs/changes/62/13762/4*04:07:44* > git rev-parse > 838b5c34127edd0450b0449e38f075f56056f2c7^{commit} # timeout=10*04:07:44* > Checking out Revision 838b5c34127edd0450b0449e38f075f56056f2c7 > (master)*04:07:44* > git config core.sparsecheckout # timeout=10*04:07:44* > > git checkout -f 838b5c34127edd0450b0449e38f075f56056f2c7*04:07:45* > git > rev-parse FETCH_HEAD^{commit} # timeout=10*04:07:45* > git rev-list > 8cbee639520bf4631ce658e2da9b4bc3010d2eaa # timeout=10*04:07:45* > git tag -a > -f -m Jenkins Build #22315 jenkins-rackspace-regression-2GB-triggered-22315 # > timeout=10 > > > > >> >>>>> >>>>> On Fri, Jul 22, 2016 at 7:44 PM, Nithya Balachandran < >>>>> nbala...@redhat.com >>>>> <javascript:_e(%7B%7D,'cvml','nbala...@redhat.com');>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri < >>>>>> pkara...@redhat.com >>>>>> <javascript:_e(%7B%7D,'cvml','pkara...@redhat.com');>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran < >>>>>>> nbala...@redhat.com >>>>>>> <javascript:_e(%7B%7D,'cvml','nbala...@redhat.com');>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <jda...@redhat.com >>>>>>>> <javascript:_e(%7B%7D,'cvml','jda...@redhat.com');>> wrote: >>>>>>>> >>>>>>>>> > I attempted to get us more space on NetBSD by creating a new >>>>>>>>> partition called >>>>>>>>> > /data and putting /build as a symlink to /data/build. This has >>>>>>>>> caused >>>>>>>>> > problems >>>>>>>>> > with tests/basic/quota.t. It's marked as bad for master, but not >>>>>>>>> for >>>>>>>>> > release-3.7. This is possibly because we have a hard-coded grep >>>>>>>>> for >>>>>>>>> > /build/install against df -h. >>>>>>>>> >>>>>>>>> For the benefit of anyone else looking at this, the grep actually >>>>>>>>> seems to be >>>>>>>>> in volume.rc and not in the test itself. >>>>>>>>> >>>>>>>> >>>>>>>> That's right - it appears to have been done to exclude the install >>>>>>>> path components from the df output which is what is being done to find >>>>>>>> the >>>>>>>> aux mount. Is there a better way to figure out if the aux mount is >>>>>>>> running? >>>>>>>> >>>>>>>>> >>>>>>>>> > Nithya has spent the last 2 days debugging >>>>>>>>> > without much success. What's a good way forward here? Mark the >>>>>>>>> test as >>>>>>>>> > failing for 3.7? >>>>>>>>> >>>>>>>> >>>>>>>> Right. Something went wrong with the system and it refused to run >>>>>>>> the tests after a while. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I don't think so. There are 13 tests that use the affected >>>>>>>>> function >>>>>>>>> (get_aux). Do we want to disable 13 tests? I think we actually >>>>>>>>> need >>>>>>>>> to fix the function instead. It seems to me that the check we're >>>>>>>>> making is very hacky in two ways: >>>>>>>>> >>>>>>>>> Checking for both /run and /var/run instead of using >>>>>>>>> GLUSTERD_WORKDIR >>>>>>>>> >>>>>>>>> Excluding /build/install for no obvious reason at all >>>>>>>>> >>>>>>>> >>>>>>>> This looks like it was done to remove the /build/install components >>>>>>>> from the df -h outputs. Changing the path to /data/build/install broke >>>>>>>> this >>>>>>>> as it did not strip the "/data" from the paths. >>>>>>>> It did work when I changed the sed to act on /data/build/install >>>>>>>> but hardcoded paths are not a good approach. >>>>>>>> >>>>>>> >>>>>>> Give me some time, I can send out a patch to print out the default >>>>>>> run directory if that helps? >>>>>>> something similar to 'gluster --print-logdir'. What shall we call >>>>>>> this? 'gluster --print-rundir'? it will >>>>>>> >>>>>>> >>>>>> >>>>>> This path might be available as an env variable - but is there a >>>>>> better way to figure out the aux mount without bothering with df -h? >>>>>> >>>>>>> >>>>>>>>> These auxiliary mounts should be in a much more specific place, >>>>>>>>> and we >>>>>>>>> should check for that instead of looking for any that might >>>>>>>>> exist. Who >>>>>>>>> knows where that place is? I've copied Raghavendra G as the quota >>>>>>>>> maintainer, since that seems like our best bet. >>>>>>>>> _______________________________________________ >>>>>>>>> Gluster-devel mailing list >>>>>>>>> Gluster-devel@gluster.org >>>>>>>>> <javascript:_e(%7B%7D,'cvml','Gluster-devel@gluster.org');> >>>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Gluster-devel mailing list >>>>>>>> Gluster-devel@gluster.org >>>>>>>> <javascript:_e(%7B%7D,'cvml','Gluster-devel@gluster.org');> >>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Pranith >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Pranith >>>>> >>>> >>>> >>>> >>>> -- >>>> Pranith >>>> >>> >> >> >> > > > -- > Pranith > -- Atin Sent from iPhone
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel