Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

Thanks Atin

On Sat, Jul 23, 2016 at 7:29 PM, Atin Mukherjee  wrote:

>
>
> On Saturday 23 July 2016, Pranith Kumar Karampuri 
> 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 
>> wrote:
>>
>>> AFAIK, an explicit rebase is required.
>>>
>>>
>>> On Saturday 23 July 2016, Pranith Kumar Karampuri 
>>> 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 
  
 (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 
>>> 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.

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Atin Mukherjee]

On Saturday 23 July 2016, Pranith Kumar Karampuri 
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  > wrote:
>
>> AFAIK, an explicit rebase is required.
>>
>>
>> On Saturday 23 July 2016, Pranith Kumar Karampuri > > 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 
>>>  (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 
>> 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 

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

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 
wrote:

> AFAIK, an explicit rebase is required.
>
>
> On Saturday 23 July 2016, Pranith Kumar Karampuri 
> 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 
>>  (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 
> 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?
>
>>

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Atin Mukherjee]

AFAIK, an explicit rebase is required.

On Saturday 23 July 2016, Pranith Kumar Karampuri 
wrote:

>
>
> On Sat, Jul 23, 2016 at 10:17 AM, Nithya Balachandran  > wrote:
>
>>
>>
>> On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran > > 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 
>  (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 > 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 

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

On Sat, Jul 23, 2016 at 10:17 AM, Nithya Balachandran 
wrote:

>
>
> On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran 
> 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

(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 
>>> 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 

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Nithya Balachandran]

On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran 
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?

>
>>>
>>> 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 
>> 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
>>
>

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

On Fri, Jul 22, 2016 at 10:25 PM, Jeff Darcy  wrote:

> > Based on what I saw in code, this seems to get the job done. Comments
> > welcome:
> > http://review.gluster.org/14988
>
> Good thinking.  Thanks, Pranith!
>

Nitya clarified my doubts as well on IRC :-).


-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Jeff Darcy]

> Based on what I saw in code, this seems to get the job done. Comments
> welcome:
> http://review.gluster.org/14988

Good thinking.  Thanks, Pranith!
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

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


>
> On Fri, Jul 22, 2016 at 7:44 PM, Nithya Balachandran 
> 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  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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

On Fri, Jul 22, 2016 at 4:46 PM, Nigel Babu  wrote:

> Hello,
>
> 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. 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?
>

Dude, she spent only 2 hours on this. Yesterday was another netbsd problem.
She is not that bad you know :-P.


>
> We're going to have to accept that some of our tests might be in a
> different
> drive as we try to get more disk space for our machines. How can we make
> our
> tests more resilient from breakage due to regular expressions?
>
> --
> nigelb
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

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


On Fri, Jul 22, 2016 at 7:44 PM, Nithya Balachandran 
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 > > wrote:
>>
>>>
>>>
>>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy  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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Jeff Darcy]

> > 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.

I agree.  What I'm worried about is that we needed to do this because
something in our code is using /build/install (or perhaps $PWD which
happens to be there) when it should be using $WORKDIR or something
like that.  If so, it sort of seems like a bug and we should probably
fix it independently of how we fix the immediate quota/NetBSD problem.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran 
wrote:

>
>
> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy  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


>
>> 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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Nithya Balachandran]

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 
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy  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
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Pranith Kumar Karampuri]

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 
> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy  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@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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Nithya Balachandran]

On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy  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.

>
> 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

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Jeff Darcy]

> 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.

> 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?

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

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

Re: [Gluster-devel] 3.7 regressions on NetBSD

[Atin Mukherjee]

On Fri, Jul 22, 2016 at 4:46 PM, Nigel Babu  wrote:

> Hello,
>
> 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. 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?
>

Yes certainly till we get to solve it, otherwise all the patches to 3.7
will be blocked.


>
> We're going to have to accept that some of our tests might be in a
> different
> drive as we try to get more disk space for our machines. How can we make
> our
> tests more resilient from breakage due to regular expressions?
>
> --
> nigelb
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 

--Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel