[Gluster-devel] Gluster Build system's voting for regression run
Hi Raghavendra, I noticed that for the below patches Gluster Build system hasn't voted and hence the verified flag doesn't have an ack from it even if the regression has passed. I think something is fishy in the script now, mind having a look? http://review.gluster.org/#/c/13222/ http://review.gluster.org/#/c/13210/ Thanks, Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Tests failing on Fedora
On 01/12/2016 07:26 PM, Raghavendra Talur wrote: > Here is the list of tests that fail on Fedora 23 machine for our master > branch. > Considering that most of them pass on upstream CentOS regression > machines, it indicates that our tests are not portable enough. > > Test Summary Report > --- > tests/basic/afr/sparse-file-self-heal.t > (Wstat: 0 Tests: 68 Failed: 2) > Failed tests: 36, 68 > tests/basic/afr/split-brain-healing.t > (Wstat: 0 Tests: 56 Failed: 9) > Failed tests: 18-26 > tests/basic/mount-nfs-auth.t >(Wstat: 0 Tests: 89 Failed: 19) > Failed tests: 16, 19-20, 24-25, 28, 31, 34-35, 38, 44-45 > 47, 51-53, 55, 60-61 > tests/basic/rpm.t > (Wstat: 0 Tests: 7 Failed: 0) > Parse errors: Bad plan. You planned 8 tests but ran 7. > tests/basic/tier/bug-1214222-directories_missing_after_attach_tier.t >(Wstat: 0 Tests: 19 Failed: 2) > Failed tests: 17-18 > tests/basic/tier/record-metadata-heat.t > (Wstat: 0 Tests: 18 Failed: 1) > Failed test: 16 > tests/basic/tier/tier.t > (Wstat: 0 Tests: 46 Failed: 1) > Failed test: 44 > tests/bugs/access-control/bug-958691.t >(Wstat: 0 Tests: 24 Failed: 2) > Failed tests: 12, 19 > tests/bugs/glusterd/bug-1260185-donot-allow-detach-commit-unnecessarily.t Gaurav, can you take a look at this failure since you are the author of this test? > (Wstat: 0 Tests: 10 Failed: 1) > Failed test: 10 > tests/bugs/glusterfs-server/bug-904300.t >(Wstat: 0 Tests: 26 Failed: 4) > Failed tests: 11-12, 23-24 > tests/bugs/quota/afr-quota-xattr-mdata-heal.t > (Wstat: 0 Tests: 104 Failed: 26) > Failed tests: 39-40, 43-46, 48-49, 52-55, 63, 71-72, 75-78 > 80-81, 84-87, 93 > tests/bugs/quota/bug-1049323.t >(Wstat: 0 Tests: 14 Failed: 1) > Failed test: 12 > tests/bugs/quota/bug-1240991.t >(Wstat: 0 Tests: 19 Failed: 2) > Failed tests: 15-16 > tests/bugs/replicate/bug-921231.t > (Wstat: 0 Tests: 11 Failed: 1) > Failed test: 11 > tests/bugs/rpc/bug-921072.t > (Wstat: 0 Tests: 67 Failed: 16) > Failed tests: 10-11, 21-22, 26-27, 30-31, 42-43, 48, 50 > 62-65 > tests/features/ipc.t >(Wstat: 0 Tests: 6 Failed: 1) > Failed test: 6 > tests/features/ssl-ciphers.t >(Wstat: 0 Tests: 78 Failed: 9) > Failed tests: 20, 24-25, 29-30, 37, 43, 51, 63 > tests/geo-rep/georep-basic-dr-rsync.t > (Wstat: 0 Tests: 58 Failed: 36) > Failed tests: 14-20, 22-25, 28-30, 32-40, 43-44, 46-52 > 55-58 > tests/geo-rep/georep-basic-dr-tarssh.t >(Wstat: 0 Tests: 59 Failed: 37) > Failed tests: 14-21, 23-26, 29-31, 33-41, 44-45, 47-53 > 56-59 > Files=459, Tests=12592, 10705 wallclock secs ( 5.75 usr 1.11 sys + > 435.83 cusr 387.48 csys = 830.17 CPU) > Result: FAIL > > > > We have a patch for one such test here http://review.gluster.org/#/c/13228/. > I request developers to pick tests from their modules and debug the issues. > It may very well be the case that the test passes in a Fedora machine > configured in a particular way, if that is the case it would be good to > document it. > > Thanks, > Raghavendra Talur > > > ___ > 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] tests/bugs/tier/bug-1286974.t failed and dropped a core
On 01/13/2016 09:14 AM, Dan Lambright wrote:
- Original Message -
From: "Niels de Vos"
To: "Dan Lambright" , "Joseph Fernandes"
Cc: gluster-devel@gluster.org
Sent: Tuesday, January 12, 2016 3:52:51 PM
Subject: tests/bugs/tier/bug-1286974.t failed and dropped a core
Hi guys,
could you please have a look at this regression test failure?
Pranith, could you or someone with EC expertise help us diagnose this problem?
The test script does:
TEST touch /mnt/glusterfs/0/file{1..100};
I see some number of errors such as:
[2016-01-12 20:14:26.888412] E [MSGID: 122063]
[ec-common.c:943:ec_prepare_update_cbk] 0-patchy-disperse-0: Unable to get size
xattr [No such file or directory]
[2016-01-12 20:14:26.888493] E [MSGID: 109031]
[dht-linkfile.c:301:dht_linkfile_setattr_cbk] 0-patchy-tier-dht: Failed to set
attr uid/gid on /file28 : [No such file or directory]
.. right before the crash. The backtrace is in mnt-glusterfs-0.log, it failed
in ec function ec_manager_setattr().
It appears to be an assert, if I found the code right.
GF_ASSERT(ec_get_inode_size(fop,
fop->locks[0].lock->loc.inode,
&cbk->iatt[0].ia_size));
/lib64/libc.so.6(+0x2b74e)[0x7f84c62a974e]
/lib64/libc.so.6(__assert_perror_fail+0x0)[0x7f84c62a9810]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x312f5)[0x7f84ba5ce2f5]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x14918)[0x7f84ba5b1918]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x10756)[0x7f84ba5ad756]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x1093c)[0x7f84ba5ad93c]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x2fbe0)[0x7f84ba5ccbe0]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x30ea9)[0x7f84ba5cdea9]
/build/install/lib/glusterfs/3.8dev/xlator/protocol/client.so(+0x1f706)[0x7f84ba854706]
/build/install/lib/libgfrpc.so.0(rpc_clnt_handle_reply+0x1b2)[0x7f84c74e542a]
This is because dht sents setattr on an inode that is not linked. For
now we are addressing it in EC with http://review.gluster.com/13039.
Regressions need to pass.
Pranith
https://build.gluster.org/job/rackspace-regression-2GB-triggered/17475/consoleFull
[20:14:46] ./tests/bugs/tier/bug-1286974.t ..
not ok 16
Failed 1/24 subtests
[20:14:46]
Test Summary Report
---
./tests/bugs/tier/bug-1286974.t (Wstat: 0 Tests: 24 Failed: 1)
Failed test: 16
Files=1, Tests=24, 37 wallclock secs ( 0.03 usr 0.01 sys + 2.38 cusr
0.77 csys = 3.19 CPU)
Result: FAIL
./tests/bugs/tier/bug-1286974.t: bad status 1
./tests/bugs/tier/bug-1286974.t: 1 new core files
Ignoring failure from known-bad test ./tests/bugs/tier/bug-1286974.t
Failures are ignored as mentioned in the last line, but cores are not
allowed. Please prevent this from happening :)
Thanks,
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] tests/bugs/tier/bug-1286974.t failed and dropped a core
- Original Message -
> From: "Niels de Vos"
> To: "Dan Lambright" , "Joseph Fernandes"
>
> Cc: gluster-devel@gluster.org
> Sent: Tuesday, January 12, 2016 3:52:51 PM
> Subject: tests/bugs/tier/bug-1286974.t failed and dropped a core
>
> Hi guys,
>
> could you please have a look at this regression test failure?
Pranith, could you or someone with EC expertise help us diagnose this problem?
The test script does:
TEST touch /mnt/glusterfs/0/file{1..100};
I see some number of errors such as:
[2016-01-12 20:14:26.888412] E [MSGID: 122063]
[ec-common.c:943:ec_prepare_update_cbk] 0-patchy-disperse-0: Unable to get size
xattr [No such file or directory]
[2016-01-12 20:14:26.888493] E [MSGID: 109031]
[dht-linkfile.c:301:dht_linkfile_setattr_cbk] 0-patchy-tier-dht: Failed to set
attr uid/gid on /file28 : [No such file or directory]
.. right before the crash. The backtrace is in mnt-glusterfs-0.log, it failed
in ec function ec_manager_setattr().
It appears to be an assert, if I found the code right.
GF_ASSERT(ec_get_inode_size(fop,
fop->locks[0].lock->loc.inode,
&cbk->iatt[0].ia_size));
/lib64/libc.so.6(+0x2b74e)[0x7f84c62a974e]
/lib64/libc.so.6(__assert_perror_fail+0x0)[0x7f84c62a9810]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x312f5)[0x7f84ba5ce2f5]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x14918)[0x7f84ba5b1918]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x10756)[0x7f84ba5ad756]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x1093c)[0x7f84ba5ad93c]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x2fbe0)[0x7f84ba5ccbe0]
/build/install/lib/glusterfs/3.8dev/xlator/cluster/disperse.so(+0x30ea9)[0x7f84ba5cdea9]
/build/install/lib/glusterfs/3.8dev/xlator/protocol/client.so(+0x1f706)[0x7f84ba854706]
/build/install/lib/libgfrpc.so.0(rpc_clnt_handle_reply+0x1b2)[0x7f84c74e542a]
>
>
> https://build.gluster.org/job/rackspace-regression-2GB-triggered/17475/consoleFull
>
> [20:14:46] ./tests/bugs/tier/bug-1286974.t ..
> not ok 16
> Failed 1/24 subtests
> [20:14:46]
>
> Test Summary Report
> ---
> ./tests/bugs/tier/bug-1286974.t (Wstat: 0 Tests: 24 Failed: 1)
> Failed test: 16
> Files=1, Tests=24, 37 wallclock secs ( 0.03 usr 0.01 sys + 2.38 cusr
> 0.77 csys = 3.19 CPU)
> Result: FAIL
> ./tests/bugs/tier/bug-1286974.t: bad status 1
> ./tests/bugs/tier/bug-1286974.t: 1 new core files
> Ignoring failure from known-bad test ./tests/bugs/tier/bug-1286974.t
>
> Failures are ignored as mentioned in the last line, but cores are not
> allowed. Please prevent this from happening :)
>
> Thanks,
> Niels
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] tests/bugs/tier/bug-1286974.t failed and dropped a core
Hi guys, could you please have a look at this regression test failure? https://build.gluster.org/job/rackspace-regression-2GB-triggered/17475/consoleFull [20:14:46] ./tests/bugs/tier/bug-1286974.t .. not ok 16 Failed 1/24 subtests [20:14:46] Test Summary Report --- ./tests/bugs/tier/bug-1286974.t (Wstat: 0 Tests: 24 Failed: 1) Failed test: 16 Files=1, Tests=24, 37 wallclock secs ( 0.03 usr 0.01 sys + 2.38 cusr 0.77 csys = 3.19 CPU) Result: FAIL ./tests/bugs/tier/bug-1286974.t: bad status 1 ./tests/bugs/tier/bug-1286974.t: 1 new core files Ignoring failure from known-bad test ./tests/bugs/tier/bug-1286974.t Failures are ignored as mentioned in the last line, but cores are not allowed. Please prevent this from happening :) Thanks, Niels signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Memory leak in GlusterFS FUSE client
I tried like suggested: echo 3 > /proc/sys/vm/drop_caches sync It lower a bit usage: before: [image: Images intégrées 2] after: [image: Images intégrées 1] Cordialement, Mathieu CHATEAU http://www.lotp.fr 2016-01-12 7:34 GMT+01:00 Mathieu Chateau : > Hello, > > I also experience high memory usage on my gluster clients. Sample : > [image: Images intégrées 1] > > Can I help in testing/debugging ? > > > > Cordialement, > Mathieu CHATEAU > http://www.lotp.fr > > 2016-01-12 7:24 GMT+01:00 Soumya Koduri : > >> >> >> On 01/11/2016 05:11 PM, Oleksandr Natalenko wrote: >> >>> Brief test shows that Ganesha stopped leaking and crashing, so it seems >>> to be good for me. >>> >>> Thanks for checking. >> >> Nevertheless, back to my original question: what about FUSE client? It >>> is still leaking despite all the fixes applied. Should it be considered >>> another issue? >>> >> >> For fuse client, I tried vfs drop_caches as suggested by Vijay in an >> earlier mail. Though all the inodes get purged, I still doesn't see much >> difference in the memory footprint drop. Need to investigate what else is >> consuming so much memory here. >> >> Thanks, >> Soumya >> >> >> >>> 11.01.2016 12:26, Soumya Koduri написав: >>> I have made changes to fix the lookup leak in a different way (as discussed with Pranith) and uploaded them in the latest patch set #4 - http://review.gluster.org/#/c/13096/ Please check if it resolves the mem leak and hopefully doesn't result in any assertion :) Thanks, Soumya On 01/08/2016 05:04 PM, Soumya Koduri wrote: > I could reproduce while testing deep directories with in the mount > point. I root caus'ed the issue & had discussion with Pranith to > understand the purpose and recommended way of taking nlookup on inodes. > > I shall make changes to my existing fix and post the patch soon. > Thanks for your patience! > > -Soumya > > On 01/07/2016 07:34 PM, Oleksandr Natalenko wrote: > >> OK, I've patched GlusterFS v3.7.6 with 43570a01 and 5cffb56b (the most >> recent >> revisions) and NFS-Ganesha v2.3.0 with 8685abfc (most recent revision >> too). >> >> On traversing GlusterFS volume with many files in one folder via NFS >> mount I >> get an assertion: >> >> === >> ganesha.nfsd: inode.c:716: __inode_forget: Assertion `inode->nlookup >> >= >> nlookup' failed. >> === >> >> I used GDB on NFS-Ganesha process to get appropriate stacktraces: >> >> 1. short stacktrace of failed thread: >> >> https://gist.github.com/7f63bb99c530d26ded18 >> >> 2. full stacktrace of failed thread: >> >> https://gist.github.com/d9bc7bc8f6a0bbff9e86 >> >> 3. short stacktrace of all threads: >> >> https://gist.github.com/f31da7725306854c719f >> >> 4. full stacktrace of all threads: >> >> https://gist.github.com/65cbc562b01211ea5612 >> >> GlusterFS volume configuration: >> >> https://gist.github.com/30f0129d16e25d4a5a52 >> >> ganesha.conf: >> >> https://gist.github.com/9b5e59b8d6d8cb84c85d >> >> How I mount NFS share: >> >> === >> mount -t nfs4 127.0.0.1:/mail_boxes /mnt/tmp -o >> defaults,_netdev,minorversion=2,noac,noacl,lookupcache=none,timeo=100 >> === >> >> On четвер, 7 січня 2016 р. 12:06:42 EET Soumya Koduri wrote: >> >>> Entries_HWMark = 500; >>> >> >> >> ___ > Gluster-users mailing list > gluster-us...@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users > ___ >> Gluster-users mailing list >> gluster-us...@gluster.org >> http://www.gluster.org/mailman/listinfo/gluster-users >> > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Memory leak in GlusterFS FUSE client
Hello, I also experience high memory usage on my gluster clients. Sample : [image: Images intégrées 1] Can I help in testing/debugging ? Cordialement, Mathieu CHATEAU http://www.lotp.fr 2016-01-12 7:24 GMT+01:00 Soumya Koduri : > > > On 01/11/2016 05:11 PM, Oleksandr Natalenko wrote: > >> Brief test shows that Ganesha stopped leaking and crashing, so it seems >> to be good for me. >> >> Thanks for checking. > > Nevertheless, back to my original question: what about FUSE client? It >> is still leaking despite all the fixes applied. Should it be considered >> another issue? >> > > For fuse client, I tried vfs drop_caches as suggested by Vijay in an > earlier mail. Though all the inodes get purged, I still doesn't see much > difference in the memory footprint drop. Need to investigate what else is > consuming so much memory here. > > Thanks, > Soumya > > > >> 11.01.2016 12:26, Soumya Koduri написав: >> >>> I have made changes to fix the lookup leak in a different way (as >>> discussed with Pranith) and uploaded them in the latest patch set #4 >>> - http://review.gluster.org/#/c/13096/ >>> >>> Please check if it resolves the mem leak and hopefully doesn't result >>> in any assertion :) >>> >>> Thanks, >>> Soumya >>> >>> On 01/08/2016 05:04 PM, Soumya Koduri wrote: >>> I could reproduce while testing deep directories with in the mount point. I root caus'ed the issue & had discussion with Pranith to understand the purpose and recommended way of taking nlookup on inodes. I shall make changes to my existing fix and post the patch soon. Thanks for your patience! -Soumya On 01/07/2016 07:34 PM, Oleksandr Natalenko wrote: > OK, I've patched GlusterFS v3.7.6 with 43570a01 and 5cffb56b (the most > recent > revisions) and NFS-Ganesha v2.3.0 with 8685abfc (most recent revision > too). > > On traversing GlusterFS volume with many files in one folder via NFS > mount I > get an assertion: > > === > ganesha.nfsd: inode.c:716: __inode_forget: Assertion `inode->nlookup >= > nlookup' failed. > === > > I used GDB on NFS-Ganesha process to get appropriate stacktraces: > > 1. short stacktrace of failed thread: > > https://gist.github.com/7f63bb99c530d26ded18 > > 2. full stacktrace of failed thread: > > https://gist.github.com/d9bc7bc8f6a0bbff9e86 > > 3. short stacktrace of all threads: > > https://gist.github.com/f31da7725306854c719f > > 4. full stacktrace of all threads: > > https://gist.github.com/65cbc562b01211ea5612 > > GlusterFS volume configuration: > > https://gist.github.com/30f0129d16e25d4a5a52 > > ganesha.conf: > > https://gist.github.com/9b5e59b8d6d8cb84c85d > > How I mount NFS share: > > === > mount -t nfs4 127.0.0.1:/mail_boxes /mnt/tmp -o > defaults,_netdev,minorversion=2,noac,noacl,lookupcache=none,timeo=100 > === > > On четвер, 7 січня 2016 р. 12:06:42 EET Soumya Koduri wrote: > >> Entries_HWMark = 500; >> > > > ___ Gluster-users mailing list gluster-us...@gluster.org http://www.gluster.org/mailman/listinfo/gluster-users >>> ___ > Gluster-users mailing list > gluster-us...@gluster.org > http://www.gluster.org/mailman/listinfo/gluster-users > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] IMPORTANT: New jenkins triggering method
-Atin Sent from one plus one On Jan 12, 2016 7:41 PM, "Niels de Vos" wrote: > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote: > > We have now changed the gerrit-jenkins workflow as follows: > > > > 1. Developer works on a new feature/bug fix and tests it locally(run > > run-tests.sh completely). > > 2. Developer sends the patch to gerrit using rfc.sh. > > > > +++Note that no regression runs have started automatically for this patch > > at this point.+++ > > > > 3. Developer marks the patch as +1 verified on gerrit as a promise of > > having tested the patch completely. For cases where patches don't have a +1 > > verified from the developer, maintainer has the following options > > a. just do the code-review and award a +2 code review. > > b. pull the patch locally and test completely and award a +1 verified. > > Both the above actions would result in triggering of regression runs for > > the patch. > > Would it not help if anyone giving +1 code-review starts the regression > tests too? When developers ask me to review, I prefer to see reviews > done by others first, and any regression failures should have been fixed > by the time I look at the change. When this idea was originated (long back) I was in favour of having regression triggered on a +1, however verified flag set by the developer would still trigger the regression. Being a maintainer I would always prefer to look at a patch when its verified flag is +1 which means the regression result would also be available. > > Niels > > > > > 4. Once the regression runs complete, verification verdict is passed onto > > gerrit by jenkins > > and maintainer can proceed with the merge using submit button. > > > > Thanks, > > Raghavendra Talur > > > ___ > > maintainers mailing list > > maintain...@gluster.org > > http://www.gluster.org/mailman/listinfo/maintainers > > > ___ > 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] [Gluster-Maintainers] IMPORTANT: New jenkins triggering method
On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote: > We have now changed the gerrit-jenkins workflow as follows: > > 1. Developer works on a new feature/bug fix and tests it locally(run > run-tests.sh completely). > 2. Developer sends the patch to gerrit using rfc.sh. > > +++Note that no regression runs have started automatically for this patch > at this point.+++ > > 3. Developer marks the patch as +1 verified on gerrit as a promise of > having tested the patch completely. For cases where patches don't have a +1 > verified from the developer, maintainer has the following options > a. just do the code-review and award a +2 code review. > b. pull the patch locally and test completely and award a +1 verified. > Both the above actions would result in triggering of regression runs for > the patch. Would it not help if anyone giving +1 code-review starts the regression tests too? When developers ask me to review, I prefer to see reviews done by others first, and any regression failures should have been fixed by the time I look at the change. Niels > > 4. Once the regression runs complete, verification verdict is passed onto > gerrit by jenkins > and maintainer can proceed with the merge using submit button. > > Thanks, > Raghavendra Talur > ___ > maintainers mailing list > maintain...@gluster.org > http://www.gluster.org/mailman/listinfo/maintainers signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Tests failing on Fedora
Here is the list of tests that fail on Fedora 23 machine for our master branch. Considering that most of them pass on upstream CentOS regression machines, it indicates that our tests are not portable enough. Test Summary Report --- tests/basic/afr/sparse-file-self-heal.t (Wstat: 0 Tests: 68 Failed: 2) Failed tests: 36, 68 tests/basic/afr/split-brain-healing.t (Wstat: 0 Tests: 56 Failed: 9) Failed tests: 18-26 tests/basic/mount-nfs-auth.t (Wstat: 0 Tests: 89 Failed: 19) Failed tests: 16, 19-20, 24-25, 28, 31, 34-35, 38, 44-45 47, 51-53, 55, 60-61 tests/basic/rpm.t (Wstat: 0 Tests: 7 Failed: 0) Parse errors: Bad plan. You planned 8 tests but ran 7. tests/basic/tier/bug-1214222-directories_missing_after_attach_tier.t (Wstat: 0 Tests: 19 Failed: 2) Failed tests: 17-18 tests/basic/tier/record-metadata-heat.t (Wstat: 0 Tests: 18 Failed: 1) Failed test: 16 tests/basic/tier/tier.t (Wstat: 0 Tests: 46 Failed: 1) Failed test: 44 tests/bugs/access-control/bug-958691.t (Wstat: 0 Tests: 24 Failed: 2) Failed tests: 12, 19 tests/bugs/glusterd/bug-1260185-donot-allow-detach-commit-unnecessarily.t (Wstat: 0 Tests: 10 Failed: 1) Failed test: 10 tests/bugs/glusterfs-server/bug-904300.t (Wstat: 0 Tests: 26 Failed: 4) Failed tests: 11-12, 23-24 tests/bugs/quota/afr-quota-xattr-mdata-heal.t (Wstat: 0 Tests: 104 Failed: 26) Failed tests: 39-40, 43-46, 48-49, 52-55, 63, 71-72, 75-78 80-81, 84-87, 93 tests/bugs/quota/bug-1049323.t (Wstat: 0 Tests: 14 Failed: 1) Failed test: 12 tests/bugs/quota/bug-1240991.t (Wstat: 0 Tests: 19 Failed: 2) Failed tests: 15-16 tests/bugs/replicate/bug-921231.t (Wstat: 0 Tests: 11 Failed: 1) Failed test: 11 tests/bugs/rpc/bug-921072.t (Wstat: 0 Tests: 67 Failed: 16) Failed tests: 10-11, 21-22, 26-27, 30-31, 42-43, 48, 50 62-65 tests/features/ipc.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 6 tests/features/ssl-ciphers.t (Wstat: 0 Tests: 78 Failed: 9) Failed tests: 20, 24-25, 29-30, 37, 43, 51, 63 tests/geo-rep/georep-basic-dr-rsync.t (Wstat: 0 Tests: 58 Failed: 36) Failed tests: 14-20, 22-25, 28-30, 32-40, 43-44, 46-52 55-58 tests/geo-rep/georep-basic-dr-tarssh.t (Wstat: 0 Tests: 59 Failed: 37) Failed tests: 14-21, 23-26, 29-31, 33-41, 44-45, 47-53 56-59 Files=459, Tests=12592, 10705 wallclock secs ( 5.75 usr 1.11 sys + 435.83 cusr 387.48 csys = 830.17 CPU) Result: FAIL We have a patch for one such test here http://review.gluster.org/#/c/13228/. I request developers to pick tests from their modules and debug the issues. It may very well be the case that the test passes in a Fedora machine configured in a particular way, if that is the case it would be good to document it. Thanks, Raghavendra Talur ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] IMPORTANT: New jenkins triggering method
We have now changed the gerrit-jenkins workflow as follows: 1. Developer works on a new feature/bug fix and tests it locally(run run-tests.sh completely). 2. Developer sends the patch to gerrit using rfc.sh. +++Note that no regression runs have started automatically for this patch at this point.+++ 3. Developer marks the patch as +1 verified on gerrit as a promise of having tested the patch completely. For cases where patches don't have a +1 verified from the developer, maintainer has the following options a. just do the code-review and award a +2 code review. b. pull the patch locally and test completely and award a +1 verified. Both the above actions would result in triggering of regression runs for the patch. 4. Once the regression runs complete, verification verdict is passed onto gerrit by jenkins and maintainer can proceed with the merge using submit button. Thanks, Raghavendra Talur ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Minutes of today's (tue 12, Jan 2016) Gluster Bug Triage meeting.
Hi all, Here are the minutes for the bug triage meeting: Minutes: http://meetbot.fedoraproject.org/gluster-meeting/2016-01-12/gluster_bug_triage.2016-01-12-12.02.html Minutes (text): http://meetbot.fedoraproject.org/gluster-meeting/2016-01-12/gluster_bug_triage.2016-01-12-12.02.txt Log: http://meetbot.fedoraproject.org/gluster-meeting/2016-01-12/gluster_bug_triage.2016-01-12-12.02.log.html Meeting summary --- * Roll Call (hgowtham, 12:02:25) * agenda: https://public.pad.fsfe.org/p/gluster-bug-triage (hgowtham, 12:02:33) * ndevos to propose some test-cases for minimal libgfapi test (hgowtham, 12:05:32) * ACTION: ndevos to propose some test-cases for minimal libgfapi test (hgowtham, 12:07:29) * Group Triage (hgowtham, 12:08:49) * LINK: https://public.pad.fsfe.org/p/gluster-bugs-to-triage (hgowtham, 12:08:59) * Open Floor (hgowtham, 12:25:51) * ACTION: Manikandan/Nandaja will keep updating status of automatic bug flow to gluster-dev ML (hgowtham, 12:26:15) Meeting ended at 12:30:21 UTC. Action Items * ndevos to propose some test-cases for minimal libgfapi test * Manikandan/Nandaja will keep updating status of automatic bug flow to gluster-dev ML Action Items, by person --- * Manikandan * Manikandan/Nandaja will keep updating status of automatic bug flow to gluster-dev ML * ndevos * ndevos to propose some test-cases for minimal libgfapi test People Present (lines said) --- * hgowtham (21) * ndevos (8) * Manikandan (5) * zodbot (3) * skoduri (1) * jiffin (1) -- Regards, Hari. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
Le mardi 12 janvier 2016 à 10:18 +0100, Niels de Vos a écrit : > On Tue, Jan 12, 2016 at 03:52:43AM -0500, Rajesh Joseph wrote: > > > > > > - Original Message - > > > From: "Niels de Vos" > > > To: "Atin Mukherjee" > > > Cc: "Gluster Devel" , "Gluster Infra" > > > > > > Sent: Tuesday, January 12, 2016 1:37:50 PM > > > Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure > > > > > > On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > > > > I've been observing freebsd smoke failure for all the patches for last > > > > few days with the following error: > > > > > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > > > > > > > Can any one from infra team can help here? > > > > > > This is not an infra issue, it is a build/installation issue in Gluster > > > that the infra caught. > > > > > > http://review.gluster.org/13208 should fix it, but I was at loss why > > > only smoke tests got triggered and regression tests not. > > > > > > > I am just wondering why are we seeing this smoke failure now and not on > > earlier patches? > > Is it a regression? I believe smoke was passing sometime back. > > I think/suspect that the FreeBSD slaves are now managed by Salt and > manual changes might have been undone. If people suggested (like now) > that this was an issue on the slave, one of the admins might have opened > up the permissions on the directories on request. Freebsd was on salt since a long time. However, I might have just run a pkg update that did reset manual change, yes. -- Michael Scherer Sysadmin, Community Infrastructure and Platform, OSAS signature.asc Description: This is a digitally signed message part ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] REMINDER: Gluster Community Bug Triage meeting (Today)
Hi all, The weekly bug triage is about to take place in ~45 minutes. Meeting details: - location: #gluster-meeting on Freenode IRC ( https://webchat.freenode.net/?channels=gluster-meeting ) - date: every Tuesday - time: 12:00 UTC (in your terminal, run: date -d "12:00 UTC") - agenda: https://public.pad.fsfe.org/p/gluster-bug-triage Currently the following items are listed: * Roll Call * Status of last weeks action items * Group Triage * Open Floor Appreciate your participation. -- Regards, Hari. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
On 01/12/2016 04:10 PM, Rajesh Joseph wrote: > > > - Original Message - >> From: "Niels de Vos" >> To: "Rajesh Joseph" >> Cc: "Atin Mukherjee" , "Gluster Devel" >> , "Gluster Infra" >> >> Sent: Tuesday, January 12, 2016 2:48:36 PM >> Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure >> >> On Tue, Jan 12, 2016 at 03:52:43AM -0500, Rajesh Joseph wrote: >>> >>> >>> - Original Message - From: "Niels de Vos" To: "Atin Mukherjee" Cc: "Gluster Devel" , "Gluster Infra" Sent: Tuesday, January 12, 2016 1:37:50 PM Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > I've been observing freebsd smoke failure for all the patches for last > few days with the following error: > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission > denied > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission > denied > > Can any one from infra team can help here? This is not an infra issue, it is a build/installation issue in Gluster that the infra caught. http://review.gluster.org/13208 should fix it, but I was at loss why only smoke tests got triggered and regression tests not. >>> >>> I am just wondering why are we seeing this smoke failure now and not on >>> earlier patches? >>> Is it a regression? I believe smoke was passing sometime back. >> >> I think/suspect that the FreeBSD slaves are now managed by Salt and >> manual changes might have been undone. If people suggested (like now) >> that this was an issue on the slave, one of the admins might have opened >> up the permissions on the directories on request. >> >> Things like this are really bugs in the build system though. >> >>> Anyway, if this is the fix then can we fast track the patch merge? >>> Thanks Niels for sending the patch. >> >> Well, the failing of the smoke test does not seem to add Verified=-1 >> anymore (no idea why)? Whats the reason of the hurry? > > I was in the impression that all smoke runs should pass. I used to check > result of smoke test before merging any patch. I guess I am wrong. No, that should be the criteria and as Niels pointed out if it fails then verified should be set to -1. We do have cases where the regression overwrites it, but in one my patch regression was never run but still it didn't set the flag to -1. > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
- Original Message - > From: "Niels de Vos" > To: "Rajesh Joseph" > Cc: "Atin Mukherjee" , "Gluster Devel" > , "Gluster Infra" > > Sent: Tuesday, January 12, 2016 2:48:36 PM > Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure > > On Tue, Jan 12, 2016 at 03:52:43AM -0500, Rajesh Joseph wrote: > > > > > > - Original Message - > > > From: "Niels de Vos" > > > To: "Atin Mukherjee" > > > Cc: "Gluster Devel" , "Gluster Infra" > > > > > > Sent: Tuesday, January 12, 2016 1:37:50 PM > > > Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure > > > > > > On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > > > > I've been observing freebsd smoke failure for all the patches for last > > > > few days with the following error: > > > > > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission > > > > denied > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission > > > > denied > > > > > > > > Can any one from infra team can help here? > > > > > > This is not an infra issue, it is a build/installation issue in Gluster > > > that the infra caught. > > > > > > http://review.gluster.org/13208 should fix it, but I was at loss why > > > only smoke tests got triggered and regression tests not. > > > > > > > I am just wondering why are we seeing this smoke failure now and not on > > earlier patches? > > Is it a regression? I believe smoke was passing sometime back. > > I think/suspect that the FreeBSD slaves are now managed by Salt and > manual changes might have been undone. If people suggested (like now) > that this was an issue on the slave, one of the admins might have opened > up the permissions on the directories on request. > > Things like this are really bugs in the build system though. > > > Anyway, if this is the fix then can we fast track the patch merge? > > Thanks Niels for sending the patch. > > Well, the failing of the smoke test does not seem to add Verified=-1 > anymore (no idea why)? Whats the reason of the hurry? I was in the impression that all smoke runs should pass. I used to check result of smoke test before merging any patch. I guess I am wrong. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] NetBSD tests not running to completion.
On 01/11/2016 01:00 PM, Pranith Kumar Karampuri wrote: On 01/09/2016 12:34 AM, Vijay Bellur wrote: On 01/08/2016 08:18 AM, Jeff Darcy wrote: I think we just need to come up with rules for considering a platform to have voting ability before merging the patch. I totally agree, except for the "just" part. ;) IMO a platform is much like a feature in terms of requiring commitment/accountability, community agreement on cost/benefit, and so on. You can see a lot of that in the feature-page template. https://github.com/gluster/glusterfs-specs/blob/master/in_progress/template.md That might provide a good starting point, even though some items won't apply to a platform and others are surely missing. It's new territory, after all. Also, I believe the bar for platforms should be higher than for features, because a new platform multiplies our test load (and associated burdens) instead of merely adding to it. Also, new features rarely impact all developers the way that new platforms do. Nobody should be making assumptions or unilateral decisions about something as important as when it is or is not OK to block all merges throughout the project. That needs to be the subject of an explicit and carefully considered community decision. That, in turn, requires some clearly defined cost/benefit analysis and resource commitment. If we don't get the process right this time, we'll end up having this same conversation yet again, and I'm sure nobody wants that. Agree here. Pranith - can you please help come up with a governance process for platforms in consultation with Jeff and Emmanuel? Once it is ready we can propose that in the broader community and formalize it. Sent the following rfc patch which will be updated based on the discussions. http://review.gluster.org/13211 I left the decisions we need to come up with as TBD in the sections. Please feel free to suggest what you would like to see there as comments on the patch. If we need more sections that we need to consider, let us add them as comments too. I will periodically refresh the patch based on the decisions that are agreed upon. + All the people who responded on the thread. Please update the patch with your suggestions. Pranith I hope the discussion will come to natural conclusions based on the discussions there. Thanks Pranith Thanks, Vijay ___ 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] [Gluster-infra] freebsd smoke failure
On Tue, Jan 12, 2016 at 03:52:43AM -0500, Rajesh Joseph wrote: > > > - Original Message - > > From: "Niels de Vos" > > To: "Atin Mukherjee" > > Cc: "Gluster Devel" , "Gluster Infra" > > > > Sent: Tuesday, January 12, 2016 1:37:50 PM > > Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure > > > > On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > > > I've been observing freebsd smoke failure for all the patches for last > > > few days with the following error: > > > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > > > > > Can any one from infra team can help here? > > > > This is not an infra issue, it is a build/installation issue in Gluster > > that the infra caught. > > > > http://review.gluster.org/13208 should fix it, but I was at loss why > > only smoke tests got triggered and regression tests not. > > > > I am just wondering why are we seeing this smoke failure now and not on > earlier patches? > Is it a regression? I believe smoke was passing sometime back. I think/suspect that the FreeBSD slaves are now managed by Salt and manual changes might have been undone. If people suggested (like now) that this was an issue on the slave, one of the admins might have opened up the permissions on the directories on request. Things like this are really bugs in the build system though. > Anyway, if this is the fix then can we fast track the patch merge? > Thanks Niels for sending the patch. Well, the failing of the smoke test does not seem to add Verified=-1 anymore (no idea why)? Whats the reason of the hurry? Niels signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
- Original Message - > From: "Niels de Vos" > To: "Atin Mukherjee" > Cc: "Gluster Devel" , "Gluster Infra" > > Sent: Tuesday, January 12, 2016 1:37:50 PM > Subject: Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure > > On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > > I've been observing freebsd smoke failure for all the patches for last > > few days with the following error: > > > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > > > Can any one from infra team can help here? > > This is not an infra issue, it is a build/installation issue in Gluster > that the infra caught. > > http://review.gluster.org/13208 should fix it, but I was at loss why > only smoke tests got triggered and regression tests not. > I am just wondering why are we seeing this smoke failure now and not on earlier patches? Is it a regression? I believe smoke was passing sometime back. Anyway, if this is the fix then can we fast track the patch merge? Thanks Niels for sending the patch. Regards, Rajesh ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
On 01/12/2016 01:37 PM, Niels de Vos wrote: > On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: >> I've been observing freebsd smoke failure for all the patches for last >> few days with the following error: >> >> mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied >> mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied >> >> Can any one from infra team can help here? > > This is not an infra issue, it is a build/installation issue in Gluster > that the infra caught. As I am not an expert at this part, my initial suspect was at infra as from the error message it looked to be the privilege issue. Never mind, Jiffin already responded on that thread. Thanks for the patch, Niels! > > http://review.gluster.org/13208 should fix it, but I was at loss why > only smoke tests got triggered and regression tests not. > > Niels > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-infra] freebsd smoke failure
On Tue, Jan 12, 2016 at 11:19:30AM +0530, Atin Mukherjee wrote: > I've been observing freebsd smoke failure for all the patches for last > few days with the following error: > > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > mkdir: /usr/local/lib/python2.7/site-packages/gluster: Permission denied > > Can any one from infra team can help here? This is not an infra issue, it is a build/installation issue in Gluster that the infra caught. http://review.gluster.org/13208 should fix it, but I was at loss why only smoke tests got triggered and regression tests not. Niels signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
