<div dir="ltr"><div>Was (Re: [Gluster-devel] Proposed Protocol changes for 4.0: Need feedback.)</div><div><br></div><div>All,</div><div><br></div>While we are at making all the below tasks' color coding to GREEN, it would make sense to discuss 1 main thing.<div><br></div><div>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?</div><div><br></div><div>If yes, I am considering some changes to the current way RPC conversion is handled in protocol layer, and make it simpler a bit.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>-Amar</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 1, 2017 at 1:00 PM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Not sure how many of you have gone through the email! As we are done with 3.12 release, gluster project is entering into a territory where goal is 4.0 but branch cut dates are not yet decided.<div><br></div><div>As protocol changes are one of the required feature for Gluster 4.0, I propose doing a day long hackathon for finishing most of the pointers mentioned below (and more if you have more proposed).</div><div><br></div><div>We can co-ordinate on #gluster-dev, and try to answer all the questions. I am happy to jump on a BJ session every 6hrs to track the progress and have more discussions if required. Plan is, after the hackathon, we have all the dependent patches for this feature out for review, and also have 'agreement' from maintainers on the approach, so they can get in together, without breaking a lot of things.</div><div><br></div><div>I propose to do it around September 3rd week. If more than 5 people are ready for it, I will plan out execution path for it further.</div><div><br></div><div>Regards,</div><div>Amar<br><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Aug 16, 2017 at 9:20 AM, Nithya Balachandran <span dir="ltr"><<a href="mailto:nbalacha@redhat.com" target="_blank">nbalacha@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 11 August 2017 at 18:04, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi All,<br><br></div>Below are the proposed protocol changes (ie, XDR changes on the wire) we are thinking for Gluster 4.0.<br><br></div><ul><li>rchecksum/fsetattr: Add 'gfid' field on wire</li></ul><p>Basic work already done at <a href="https://review.gluster.org/#/c/3956/" target="_blank">https://review.gluster.org/#/c<wbr>/3956/</a> . Considering its 5yrs old patch, I refreshed it at <a href="https://review.gluster.org/17656" target="_blank">https://review.gluster.org/176<wbr>56</a> for experimental branch, and it is all working fine.</p><p>This patch also helps in creating new RPC program etc, so for all other XDR changes, we only need to handle the specific change in the patch.</p><p><span style="color:rgb(0,255,0)">STATUS: GREEN</span><br></p><ul><li>statx() support</li></ul><p><a href="https://github.com/gluster/glusterfs/issues/273" target="_blank">https://github.com/gluster/glu<wbr>sterfs/issues/273</a> talks more on it. We can consider to make XDR changes for sure even if we don't implement the fops in all other xlator IMO, so there won't be clients' compatibility issue.</p><p><span style="color:rgb(255,0,0)">STATUS: RED </span>(As no work has been started yet)</p><ul><li>Changes to 'gf_flock' structure on wire</li></ul><p>More on it @ <a href="https://review.gluster.org/#/c/15698" target="_blank">https://review.gluster.org/#/c<wbr>/15698</a>. Can be handled without this change by using xdata, but adding this field in the XDR will make it faster, and less error prone.</p><p><span style="color:rgb(255,255,0)">STATUS: YELLOW</span></p><ul><li>Changes in few of the 'fops' to get struct iatt in _cbk</li></ul><p>This is needed for mainly handling the cases of fail over during rebalance, self-heal etc. Today, because we don't have a protocol support, our cross architecture compatibility is broken, mainly because we send iatt as binary in xdata dict, which is not desirable.</p></div></blockquote><div><br></div></span><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><p><span style="color:rgb(255,0,0)">STATUS: RED</span></p><p>(Red as we need to hear from team on what are the changes needed, and it would be significant change as we may have to change the fops signature itself).</p><ul><li>fadvise()</li></ul><p>As per the email thread <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-August/053457.html" target="_blank">http://lists.gluster.org/piper<wbr>mail/gluster-devel/2017-August<wbr>/053457.html</a>, if we implement the fop, we would need a new XDR for it.</p><p><span style="color:rgb(255,0,0)">STATUS: RED</span></p><p>(It is red as it is still in discovery phase)<br></p><ul><li>Misc</li></ul><p>We don't have any other proposal for protocol change for now, other than a suggestion from Jeff Darcy about taking out the common flags we use across the board, inside xdata, and make them as 'flags' itself in XDR, for better perf, and manageability. <br></p><p><span style="color:rgb(255,0,0)">STATUS: RED <br></span></p><p>(Mainly because the work is about discovery and changing the fops signature itself).</p><p><br></p><p>This is the good time to highlight if you need any further changes in protocol itself, and start towards getting it implemented and tested. I volunteer to review all such patches, and happy to co-ordinate it on experimental branch before sending them as a single patch (or multiple dependent, granular patches) on master when we feel it is ready.</p><p><br></p><p>Regards,<br></p><p>Amar<span class="m_-1362235469538974035m_997585311136200945HOEnZb"><font color="#888888"><br></font></span></p><span class="m_-1362235469538974035m_997585311136200945HOEnZb"><font color="#888888"><p><br></p><div><div><div>-- <br><div class="m_-1362235469538974035m_997585311136200945m_8688057491948380649gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div></div></font></span></div>
<br></span>______________________________<wbr>_________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/maintainers</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-1362235469538974035gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>