[Gluster-devel] [Gluster-Maintainers] Client Server incompatibility with Gluster 4.0
Shyam Ranganathan
srangana at redhat.com
Thu Oct 12 14:22:22 UTC 2017
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.
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.
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.
>
> 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
>
More information about the Gluster-devel
mailing list