[Gluster-devel] 3.7 regressions on NetBSD

[Nithya Balachandran]

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?

>
>>>
>>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160723/493113b3/attachment-0001.html>