On Thu, Oct 12, 2017 at 10:22 AM, Shyam Ranganathan <srangana@xxxxxxxxxx> wrote:
On 10/12/2017 04:25 AM, Ric Wheeler wrote:
I worry about having to update all of the clients when we have new code on servers.
Typically, for example with NFS, the client negotiates the protocol version it understands and we default to the highest version the clients and servers both support.
I know that is a pain, but we should keep in mind what the standard is our users are accustomed to with other protocols....
I concur, upgrade to 4.0, if the older clients are not compatible, would mean a down client(s) upgrade.
Thinking more about it, we could leverage the op-version infrastructure to maintain compatibility at a cluster/volume level. This could help by not requiring the clients to be upgraded simultaneously with the servers. However, as with current behavior, once a 4.0 feature that is disruptive to 3.x clients is enabled, such clients would not be able to access those volumes with advanced capabilities.
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.
Kaushal, Atin - can you please share details on how the upgrade process would look like from a glusterd perspective?
Which then essentially boils down to, stop services, upgrade everything, and restart the volume and the clients.
I understand the additional code and reasoning that Amar has pointed out, but taking down time for the upgrade will introduce a lot of pain for the users, and hence create resistance to upgrading to 4.0 probable and in some cases (consider the service using the gluster volume critical) not possible.
As we are about providing increased availability considering replication and the additional storage that it involves, down time for upgrades should not be a choice that we should consider, when possible.
Agreed. We can and should reduce the user pain for this upgrade. Let us also explore ways to keep our code clean and prevent that from becoming a spaghetti mess :-).
Regards,
Vijay
Regards,
Ric
On Oct 12, 2017 6:30 AM, "Vijay Bellur" <vbellur@xxxxxxxxxx <mailto:vbellur@xxxxxxxxxx>> wrote:
On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <atumball@xxxxxxxxxxGluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@gluster.<mailto:atumball@xxxxxxxxxx>> wrote:
Was (Re: Proposed Protocol changes for 4.0: Need
feedback.)
All,
While we are at making all the below tasks' color coding to
GREEN, it would make sense to discuss 1 main thing.
With 4.0, we will anyways say 3.y series server nodes are not
going to be compatible with 4.x servers, is it the same case
with clients?
If yes, I am considering some changes to the current way RPC
conversion is handled in protocol layer, and make it simpler a bit.
If no, then I have to add lot of 'if..else' in existing code or
extra code wherever applicable, now, to make sure we handle the
compatibility better.
My personal opinion is, talk about incompatibility now, and plan
to have smooth sail even when 5.0 lands. We are anyways coming
out with GD2 (which makes servers incompatible), and gfproxy
(which makes clients missing this feature in older releases),
and also possible cherrypicks from upstream fuse project to
utilize more features from there, so for the user, there are lot
of reason to upgrade the clients.
Since we are bumping the major release number, I think it would be
acceptable to have 3.x clients being not compatible with 4.x servers
and vice-versa. We should ensure that accesses from incompatible
clients are handled gracefully by both servers and clients.
Regards,
Vijay
_______________________________________________
Gluster-devel mailing listorg >
http://lists.gluster.org/mailman/listinfo/gluster-devel
<http://lists.gluster.org/mailman/listinfo/gluster-devel >
_______________________________________________
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
