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@xxxxxxxxxx
<mailto:vbellur@xxxxxxxxxx>> wrote:
On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <atumball@xxxxxxxxxx
<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 list
Gluster-devel@xxxxxxxxxxx <mailto:Gluster-devel@xxxxxxxxxxx>
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
