On Thu, Oct 12, 2017 at 10:22 AM, Shyam Ranganathan <[email protected]> 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" <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> >> On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> <http://lists.gluster.org/mailman/listinfo/gluster-devel> >> >> >> >> _______________________________________________ >> Gluster-devel mailing list >> [email protected] >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> >>
_______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
