<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 12, 2017 at 10:22 AM, Shyam Ranganathan <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/12/2017 04:25 AM, Ric Wheeler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I worry about having to update all of the clients when we have new code on servers.<br>
<br>
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.<br>
<br>
I know that is a pain, but we should keep in mind what the standard is our users are accustomed to with other protocols....<br>
</blockquote>
<br></span>
I concur, upgrade to 4.0, if the older clients are not compatible, would mean a down client(s) upgrade.<br></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>Kaushal, Atin - can you please share details on how the upgrade process would look like from a glusterd perspective?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Which then essentially boils down to, stop services, upgrade everything, and restart the volume and the clients.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div><br></div><div>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 :-).</div><div><br></div><div><br></div><div>Regards,</div><div>Vijay</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<br>
Ric<span class=""><br>
<br>
<br>
On Oct 12, 2017 6:30 AM, "Vijay Bellur" <<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a> <mailto:<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>>> wrote:<br>
<br>
<br>
<br>
On Wed, Oct 11, 2017 at 5:06 AM, Amar Tumballi <<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>>> wrote:<br>
<br>
Was (Re: [Gluster-devel] Proposed Protocol changes for 4.0: Need<br>
feedback.)<br>
<br>
All,<br>
<br>
While we are at making all the below tasks' color coding to<br>
GREEN, it would make sense to discuss 1 main thing.<br>
<br>
With 4.0, we will anyways say 3.y series server nodes are not<br>
going to be compatible with 4.x servers, is it the same case<br>
with clients?<br>
<br>
If yes, I am considering some changes to the current way RPC<br>
conversion is handled in protocol layer, and make it simpler a bit.<br>
<br>
If no, then I have to add lot of 'if..else' in existing code or<br>
extra code wherever applicable, now, to make sure we handle the<br>
compatibility better.<br>
<br>
My personal opinion is, talk about incompatibility now, and plan<br>
to have smooth sail even when 5.0 lands. We are anyways coming<br>
out with GD2 (which makes servers incompatible), and gfproxy<br>
(which makes clients missing this feature in older releases),<br>
and also possible cherrypicks from upstream fuse project to<br>
utilize more features from there, so for the user, there are lot<br>
of reason to upgrade the clients.<br>
<br>
<br>
<br>
Since we are bumping the major release number, I think it would be<br>
acceptable to have 3.x clients being not compatible with 4.x servers<br>
and vice-versa. We should ensure that accesses from incompatible<br>
clients are handled gracefully by both servers and clients.<br>
<br>
Regards,<br>
Vijay<br>
<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br></div></div>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a> <mailto:<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.<wbr>org</a>><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
<<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mail<wbr>man/listinfo/gluster-devel</a>><span class=""><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-devel</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div></div>