[Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

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
>

Wait, it seems like 'gluster --print-statedumpdir' already prints
'/var/run/gluster', is this the directory we want?


>
>
>>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160722/1ca62204/attachment.html>