On Tue, Feb 13, 2018 at 11:12 AM, Shyam Ranganathan <srang...@redhat.com> wrote:
> On 02/13/2018 12:35 AM, Atin Mukherjee wrote: > > > > > > On Tue, Feb 13, 2018 at 10:43 AM, Jiffin Tony Thottan > > <jthot...@redhat.com <mailto:jthot...@redhat.com>> wrote: > > > > Since the change was there from 3.10 onwards, only upgrade from > > eoled version to stable will break right? > > > > I didn't notice anyone complaining about the issue in community till > > now. > > > > > > If any one upgrades the cluster from < 3.10 to >= 3.10, it's a genuine > > problem as per my code reading. > > So I tested 3.9 -> 3.10 -> 3.12 -> 3.13 upgrades (during release times). > Actually n-1 to n where 'n' is the current release. > I looked into this a bit more and found what's happening here. If you test the upgrade path where target version is <3.10.8 or 3.13.0 or 3.12.3 from < 3.10 you're good. This bug was made exposed because of the fix for the bug I pointed out below. Post upgrade when bricks restart, the patch of the below fix was dumping the volinfo into the disk because of which even if the cluster.op-version is not bumped up then we expose this issue. glusterfs-3.10.8 - https://bugzilla.redhat.com/show_bug.cgi?id=1507752 glusterfs-3.13.0 - https://bugzilla.redhat.com/show_bug.cgi?id=1506589 glusterfs-3.12.3 - https://bugzilla.redhat.com/show_bug.cgi?id=1507748 > What I do *not* test is every option that can be enabled, and the > resultant upgrade scenario. (which I believe we should do) > For this case, we didn't need to explicitly turn on any option. Its just that a new in-memory field which was introduced in volinfo which gets written to the disk. > What is the shortest way to at *least* test, > - added options > - changed options > for a release? > > > > > > > -- > > > > Jiffin > > > > > > > > On Tuesday 13 February 2018 08:21 AM, Hari Gowtham wrote: > > > > I'm working on it. > > > > On Tue, Feb 13, 2018 at 8:11 AM, Atin Mukherjee > > <amukh...@redhat.com <mailto:amukh...@redhat.com>> wrote: > > > > FYI.. We need to backport > > https://review.gluster.org/#/c/19552 > > <https://review.gluster.org/#/c/19552> (yet to be > > merged in mainline) in all the active release branches to > > avoid users to get > > into upgrade failures. The bug and the commit has the > > further details. > > > > > > > > > > > > > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://lists.gluster.org/mailman/listinfo/gluster-devel > > >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel