If someone could give +1 on 3.7 backport http://review.gluster.org/#/c/14991, I can merge the patch. Then we can start rebasing may be?
On Sat, Jul 23, 2016 at 12:23 PM, Atin Mukherjee <amukh...@redhat.com> wrote: > 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> wrote: >> >>> >>> >>> On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran < >>> nbala...@redhat.com> wrote: >>> >>>> >>>> >>>> On Fri, Jul 22, 2016 at 9:07 PM, Pranith Kumar Karampuri < >>>> pkara...@redhat.com> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Jul 22, 2016 at 8:12 PM, Pranith Kumar Karampuri < >>>>> 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> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri < >>>>>>> pkara...@redhat.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran < >>>>>>>> nbala...@redhat.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <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 >>>>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Gluster-devel mailing list >>>>>>>>> Gluster-devel@gluster.org >>>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Pranith >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Pranith >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Pranith >>>>> >>>> >>> >>> >>> >> >> >> -- >> Pranith >> > > > -- > Atin > Sent from iPhone > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel