[Gluster-devel] Release 6.1: Expected tagging on April 10th
Atin Mukherjee
amukherj at redhat.com
Tue Apr 16 17:11:10 UTC 2019
On Tue, Apr 16, 2019 at 10:26 PM Atin Mukherjee <amukherj at redhat.com> wrote:
>
>
> On Tue, Apr 16, 2019 at 9:19 PM Atin Mukherjee <amukherj at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Apr 16, 2019 at 7:24 PM Shyam Ranganathan <srangana at 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 <pkarampu at 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 <pkarampu at 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 at 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 <ravishankar at redhat.com
>>> > <mailto:ravishankar at 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-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>>> > > https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> > _______________________________________________
>>> > Gluster-devel mailing list
>>> > Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> >
>>> >
>>> > --
>>> > - Atin (atinm)
>>> >
>>> > _______________________________________________
>>> > Gluster-devel mailing list
>>> > Gluster-devel at gluster.org
>>> > https://lists.gluster.org/mailman/listinfo/gluster-devel
>>> >
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190416/3a1e4ee6/attachment.html>
More information about the Gluster-devel
mailing list