Re: [Gluster-Maintainers] Client Server incompatibility with Gluster 4.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 12 Oct 2017 at 20:45, Shyam Ranganathan <srangana@xxxxxxxxxx> wrote:
On 10/12/2017 11:03 AM, Vijay Bellur wrote:
>     Further, rolling upgrades of the server becomes a moot point, as
>     some would be a higher version in the interim and hence prevent
>     existing clients to talk to the same, as our upgrade process is
>     servers first and then clients.
>
>
> I do not think we will have rolling upgrades on the server side as we
> would need glusterd1 and glusterd2 to interoperate for that. From what I
> understand, we will not have that interoperability. A downtime would be
> needed for upgrading servers although the expectation is that upgrading
> the servers would happen quickly.

My thoughts on this as Atin/Kaushal respond (which would probably be
more definitive anyway).

I would think migrating to GD2 is a separate step by itself, when
upgrading an existing cluster, it remains in GD1, and then a separate
GD2 upgrade/migration step(s) is executed.

Further this upgrade/migration would need to be actively supported for 2
LTM releases (or for a year roughly), at which point it is all GD2
anyway, IOW the 3rd STM/LTM will work only if the cluster is anready on GD2.

Older clusters that are still on GD1/older LTM release at the end of the
years mark, will need a 2 step upgrade (upgrade to an older LTM where
GD2 was introduced and supports the migration, then upgrade to the
latest release).

You covered all the points. That’s how it is planned. And to add, all the upgrade migrations path (from GD1 to GD2) will need to be carried offline sincetge configuration data layout for GD2 changes from file based store to etcd data.

Kaushal - please add if you have more insights.



Of course, the latter should be announced as early as possible and so
that users have time to understand that postponing the update to GD2
will incur a 2 step process.

>
> Kaushal, Atin - can you please share details on how the upgrade process
> would look like from a glusterd perspective?
--
- Atin (atinm)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux