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....
Regards,
Ric
On Oct 12, 2017 6:30 AM, "Vijay Bellur" <vbellur@xxxxxxxxxx> wrote:
On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <atumball@xxxxxxxxxx> 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@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel