<div dir="ltr">If we plan to fix, bz [1] is another candidate that has to be targeted for 4.0.<br><span id="gmail-summary_alias_container"><span id="gmail-short_desc_nonedit_display"><br>Gluster's XDR does not conform to RFC spec</span></span><pre class="gmail-bz_comment_text gmail-bz_wrap_comment_text" id="gmail-comment_text_0">Description of problem: In an attempt to generate bindings to Gluster's XDR with Rust I've run into a few problems. It appears the XDR .x spec files are using keywords that are not legal according to the RFC spec <a href="https://tools.ietf.org/html/rfc4506.html">https://tools.ietf.org/html/rfc4506.html</a>. This hinders language adoption of Gluster. If anyone would like to produce pure language bindings this prevents them from succeeding. Indeed I think community adoption of Gluster would benefit from having a wider range of XDR bindings on which to build tooling.
Some of the problems I've encountered:
1. RFC4506 doesn't define "long" as a basic type in .x files; unsigned hyper is its 64 bit unsigned type.
2. Also unsigned char uuid[16] not defined
Possibly other problems that I haven't gotten to yet as the parser moves through the files.
Version-Release number of selected component (if applicable):
How reproducible: Always reproducible.</pre><div><br>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1336889">https://bugzilla.redhat.com/show_bug.cgi?id=1336889</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 1, 2017 at 2:29 PM, Soumya Koduri <span dir="ltr"><<a href="mailto:skoduri@redhat.com" target="_blank">skoduri@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=""><br>
<br>
On 08/11/2017 06:04 PM, Amar Tumballi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi All,<br>
<br>
Below are the proposed protocol changes (ie, XDR changes on the wire) we are thinking for Gluster 4.0.<br>
</blockquote>
<br></span>
Poornima and I were discussing if we can include volume uuid as part of Handshake protocol between protocol/client and protocol/server so that clients do not re-connect if the volume was deleted and recreated with the same name, eliminating potential issues at upper layers [1].<br>
<br>
We haven't looked into details, but the idea is to have glusterd2 send volume uuid as part of GETSPEC request to clients & brick processes which shall be used by protocol/client & protocol/server (may be along with vol name as well) during HNDSK_SETVOLUME.<br>
<br>
Poornima/Ram,<br>
<br>
Please add if I missed out anything.<br>
<br>
Thanks,<br>
Soumya<br>
<br>
<br>
[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1463191" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1463191</a><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</div>