Thanks Vijay, Ric, and Shyam.
--
Just to re-iterate, our RPC layer is designed to handle multiple version of protocols, and smoothly work with different clients. But I noticed that in the last 4 years, it was not properly followed, and for the same version we ended up making on wire changes, thus causing client incompatibility. This was bad because clients thought server supported the version they knew, but server wanted few requests differently on wire, causing issues.
My intention to send the email was to make sure we are all on same page with upgrade process after Gluster 4.0, If every other components are working with rolling upgrade or handling the older clients etc, then we had to do the extra work of supporting old and new protocol, but if we are already breaking it in different components, then we could have saved few days of extra work.
For now, with the discussions, I would like to assume we will still have clients which are older with upgrade to 4.0 version, and they can move to higher version later than the server.
Thanks,
Amar
On Thu, Oct 12, 2017 at 8:45 PM, 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).
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?
_______________________________________________
maintainers mailing list
maintainers@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/maintainers
Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
