[Gluster-Maintainers] [Gluster-devel] Client Server incompatibility with Gluster 4.0

[Vijay Bellur]

On Thu, Oct 12, 2017 at 10:22 AM, Shyam Ranganathan <srangana at redhat.com>
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 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
>>         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 list
>>     Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>>     http://lists.gluster.org/mailman/listinfo/gluster-devel
>>     <http://lists.gluster.org/mailman/listinfo/gluster-devel>
>>
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20171012/4b572a4d/attachment-0001.html>