Re: IMP: upgrade issue

[Atin Mukherjee <amukherj@xxxxxxxxxx>]

On Tue, Feb 13, 2018 at 11:12 AM, Shyam Ranganathan <srangana@xxxxxxxxxx> wrote:

On 02/13/2018 12:35 AM, Atin Mukherjee wrote:
>
>
> On Tue, Feb 13, 2018 at 10:43 AM, Jiffin Tony Thottan
> <jthottan@xxxxxxxxxx <mailto:jthottan@xxxxxxxxxx>> 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
>         <amukherj@xxxxxxxxxx <mailto:amukherj@xxxxxxxxxx>> 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@xxxxxxxxxxx
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>

_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel