On Tue, Apr 16, 2019 at 10:26 PM Atin Mukherjee <amukh...@redhat.com> wrote:
> > > On Tue, Apr 16, 2019 at 9:19 PM Atin Mukherjee <amukh...@redhat.com> > wrote: > >> >> >> On Tue, Apr 16, 2019 at 7:24 PM Shyam Ranganathan <srang...@redhat.com> >> wrote: >> >>> Status: Tagging pending >>> >>> Waiting on patches: >>> (Kotresh/Atin) - glusterd: fix loading ctime in client graph logic >>> https://review.gluster.org/c/glusterfs/+/22579 >> >> >> The regression doesn't pass for the mainline patch. I believe master is >> broken now. With latest master sdfs-sanity.t always fail. We either need to >> fix it or mark it as bad test. >> > > commit 3883887427a7f2dc458a9773e05f7c8ce8e62301 (HEAD) > Author: Pranith Kumar K <pkara...@redhat.com> > Date: Mon Apr 1 11:14:56 2019 +0530 > > features/locks: error-out {inode,entry}lk fops with all-zero lk-owner > > Problem: > Sometimes we find that developers forget to assign lk-owner for an > inodelk/entrylk/lk before writing code to wind these fops. locks > xlator at the moment allows this operation. This leads to multiple > threads in the same client being able to get locks on the inode > because lk-owner is same and transport is same. So isolation > with locks can't be achieved. > > Fix: > Disallow locks with lk-owner zero. > > fixes bz#1624701 > Change-Id: I1c816280cffd150ebb392e3dcd4d21007cdd767f > Signed-off-by: Pranith Kumar K <pkara...@redhat.com> > > With the above commit sdfs-sanity.t started failing. But when I looked at > the last regression vote at > https://build.gluster.org/job/centos7-regression/5568/consoleFull I saw > it voted back positive but the bell rang when I saw the overall regression > took less than 2 hours and when I opened the regression link I saw the test > actually failed but still this job voted back +1 at gerrit. > > *Deepshika* - *This is a bad CI bug we have now and have to be addressed > at earliest. Please take a look at > https://build.gluster.org/job/centos7-regression/5568/consoleFull > <https://build.gluster.org/job/centos7-regression/5568/consoleFull> and > investigate why the regression vote wasn't negative.* > > Pranith - I request you to investigate on the sdfs-sanity.t failure > because of this patch. > > *@Maintainers - Please open up every regression link to see the actual > status of the job and don't blindly trust on the +1 vote back at gerrit > till this is addressed.* > > As per the policy, I'm going to revert this commit, watch out for the > patch. > https://review.gluster.org/#/c/glusterfs/+/22581/ Please review and merge it. Also since we're already close to 23:00 in IST timezone, I need help from folks from other timezone in getting https://review.gluster.org/#/c/glusterfs/+/22578/ rebased and marked verified +1 once the above fix is merged. This is a blocker to glusterfs-6.1 as otherwise ctime feature option tuning isn't honoured. I request this to be directly pushed with out waiting for the regression > vote as we had done before in such breakage. Amar/Shyam - I believe you > have this permission? > > >> root@a5f81bd447c2:/home/glusterfs# prove -vf tests/basic/sdfs-sanity.t >> tests/basic/sdfs-sanity.t .. >> 1..7 >> ok 1, LINENUM:8 >> ok 2, LINENUM:9 >> ok 3, LINENUM:11 >> ok 4, LINENUM:12 >> ok 5, LINENUM:13 >> ok 6, LINENUM:16 >> mkdir: cannot create directory ‘/mnt/glusterfs/1/coverage’: Invalid >> argument >> stat: cannot stat '/mnt/glusterfs/1/coverage/dir': Invalid argument >> tests/basic/rpc-coverage.sh: line 61: test: ==: unary operator expected >> not ok 7 , LINENUM:20 >> FAILED COMMAND: tests/basic/rpc-coverage.sh /mnt/glusterfs/1 >> Failed 1/7 subtests >> >> Test Summary Report >> ------------------- >> tests/basic/sdfs-sanity.t (Wstat: 0 Tests: 7 Failed: 1) >> Failed test: 7 >> Files=1, Tests=7, 14 wallclock secs ( 0.02 usr 0.00 sys + 0.58 cusr >> 0.67 csys = 1.27 CPU) >> Result: FAIL >> >> >>> >>> Following patches will not be taken in if CentOS regression does not >>> pass by tomorrow morning Eastern TZ, >>> (Pranith/KingLongMee) - cluster-syncop: avoid duplicate unlock of >>> inodelk/entrylk >>> https://review.gluster.org/c/glusterfs/+/22385 >>> (Aravinda) - geo-rep: IPv6 support >>> https://review.gluster.org/c/glusterfs/+/22488 >>> (Aravinda) - geo-rep: fix integer config validation >>> https://review.gluster.org/c/glusterfs/+/22489 >>> >>> Tracker bug status: >>> (Ravi) - Bug 1693155 - Excessive AFR messages from gluster showing in >>> RHGSWA. >>> All patches are merged, but none of the patches adds the "Fixes" >>> keyword, assume this is an oversight and that the bug is fixed in this >>> release. >>> >>> (Atin) - Bug 1698131 - multiple glusterfsd processes being launched for >>> the same brick, causing transport endpoint not connected >>> No work has occurred post logs upload to bug, restart of bircks and >>> possibly glusterd is the existing workaround when the bug is hit. Moving >>> this out of the tracker for 6.1. >>> >>> (Xavi) - Bug 1699917 - I/O error on writes to a disperse volume when >>> replace-brick is executed >>> Very recent bug (15th April), does not seem to have any critical data >>> corruption or service availability issues, planning on not waiting for >>> the fix in 6.1 >>> >>> - Shyam >>> On 4/6/19 4:38 AM, Atin Mukherjee wrote: >>> > Hi Mohit, >>> > >>> > https://review.gluster.org/22495 should get into 6.1 as it’s a >>> > regression. Can you please attach the respective bug to the tracker >>> Ravi >>> > pointed out? >>> > >>> > >>> > On Sat, 6 Apr 2019 at 12:00, Ravishankar N <ravishan...@redhat.com >>> > <mailto:ravishan...@redhat.com>> wrote: >>> > >>> > Tracker bug is https://bugzilla.redhat.com/show_bug.cgi?id=1692394, >>> in >>> > case anyone wants to add blocker bugs. >>> > >>> > >>> > On 05/04/19 8:03 PM, Shyam Ranganathan wrote: >>> > > Hi, >>> > > >>> > > Expected tagging date for release-6.1 is on April, 10th, 2019. >>> > > >>> > > Please ensure required patches are backported and also are >>> passing >>> > > regressions and are appropriately reviewed for easy merging and >>> > tagging >>> > > on the date. >>> > > >>> > > Thanks, >>> > > Shyam >>> > > _______________________________________________ >>> > > Gluster-devel mailing list >>> > > gluster-de...@gluster.org <mailto:gluster-de...@gluster.org> >>> > > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > _______________________________________________ >>> > Gluster-devel mailing list >>> > gluster-de...@gluster.org <mailto:gluster-de...@gluster.org> >>> > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > >>> > >>> > -- >>> > - Atin (atinm) >>> > >>> > _______________________________________________ >>> > Gluster-devel mailing list >>> > gluster-de...@gluster.org >>> > https://lists.gluster.org/mailman/listinfo/gluster-devel >>> > >>> _______________________________________________ >>> Gluster-devel mailing list >>> gluster-de...@gluster.org >>> https://lists.gluster.org/mailman/listinfo/gluster-devel >> >>
_______________________________________________ maintainers mailing list maintainers@gluster.org https://lists.gluster.org/mailman/listinfo/maintainers