[Gluster-devel] 3.7 regressions on NetBSD

Pranith Kumar Karampuri pkarampu at redhat.com
Sat Jul 23 06:46:34 UTC 2016 

On Sat, Jul 23, 2016 at 10:17 AM, Nithya Balachandran <nbalacha at redhat.com>
wrote:

>
>
> On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran <nbalacha at redhat.com>
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 9:07 PM, Pranith Kumar Karampuri <
>> pkarampu at redhat.com> wrote:
>>
>>>
>>>
>>> On Fri, Jul 22, 2016 at 8:12 PM, Pranith Kumar Karampuri <
>>> pkarampu at 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 <
>>>> nbalacha at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri <
>>>>> pkarampu at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran <
>>>>>> nbalacha at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <jdarcy at 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 at gluster.org
>>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Gluster-devel mailing list
>>>>>>> Gluster-devel at gluster.org
>>>>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pranith
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Pranith
>>>>
>>>
>>>
>>>
>>> --
>>> Pranith
>>>
>>
>
>
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160723/579799ef/attachment.html>

More information about the Gluster-devel mailing list