[Gluster-devel] [Gluster-Maintainers] Client Server incompatibility with Gluster 4.0
vbellur at redhat.com
Thu Oct 12 15:03:49 UTC 2017
On Thu, Oct 12, 2017 at 10:22 AM, Shyam Ranganathan <srangana at redhat.com>
> 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
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 :-).
>> On Oct 12, 2017 6:30 AM, "Vijay Bellur" <vbellur at redhat.com <mailto:
>> vbellur at redhat.com>> wrote:
>> On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <atumball at redhat.com
>> <mailto:atumball at redhat.com>> wrote:
>> Was (Re: [Gluster-devel] Proposed Protocol changes for 4.0: Need
>> 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
>> 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.
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel