On Saturday 23 July 2016, Pranith Kumar Karampuri <pkara...@redhat.com> wrote:
> 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? > Merged! > > On Sat, Jul 23, 2016 at 12:23 PM, Atin Mukherjee <amukh...@redhat.com > <javascript:_e(%7B%7D,'cvml','amukh...@redhat.com');>> wrote: > >> AFAIK, an explicit rebase is required. >> >> >> On Saturday 23 July 2016, Pranith Kumar Karampuri <pkara...@redhat.com >> <javascript:_e(%7B%7D,'cvml','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 > -- --Atin
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel