[Gluster-devel] Stable numbering of RPC procedures

[Niels de Vos]

On Tue, Jun 18, 2013 at 06:30:47AM +0530, Amar Tumballi wrote:
> On 06/17/2013 02:39 PM, Niels de Vos wrote:
> >On Fri, Jun 14, 2013 at 12:07:51PM -0700, Anand Avati wrote:
> >>On Fri, Jun 14, 2013 at 1:40 AM, Bharata B Rao <bharata.rao at gmail.com>wrote:
> >>
> >>>On Mon, Jun 3, 2013 at 9:12 PM, Anand Avati <anand.avati at gmail.com> wrote:
> >>>>This looks more like a compile time feature check than runtime. The
> >>>>PKG_CONFIG() api number which had the initial set of QEMU requirements
> >>>was 3
> >>>>(i.e, PKG_CONFIG(..,glusterfs-api>=3,..). The new updates for Samba
> >>>>requirements has api number 4. Depending on whether discard support
> >>>makes it
> >>>>before the next release (and api numbers gets published) or not,
> >>>>glfs_discard() would either be available in 4 or 5. Also, you might also
> >>>>want to add a second AC_CHECK_FUNC macro in configure.ac to be doubly
> >>>sure.
> >>>
> >>>Now with fallocate and discard support upstream, are you planning to
> >>>increment the glusterfs-api version ? I still see the version as 4 in
> >>>the git master. I need to decide if I should use version 4 or 5 to
> >>>determine the availability of discard support from QEMU.
> >>>
> >>
> >>
> >>This is yet to be determined. The fallocate/discard introduces change in
> >>the internal protocol/rpc and we're figuring out the right time to bring
> >>this patch into a release branch. Since release-3.4 is still "unreleased"
> >>there is a possibility, but we have not yet decided on it.
> >
> >I've just looked at the latest additions to the protocol/rpc procedures.
> >If these changes have not made it to a release, please consider
> >including this change first:
> >- http://review.gluster.org/5215
> >
> >Currently posted as RFC, no Bug yet. Let me know if this change is still
> >possible, and I'll file a Bug and repost. I'll await your response
> >before sending patches to the Wireshark project. (I need to know that
> >the number of the new RPC procedures is stable.)
> >
> 
> I looked at initial patch and the new one. Adding it to the end of
> the procedure list is surely better than adding them at the middle.
> But, in long run, its not good to make changes to existing version
> number itself. Any new changes to released RPC program spec should
> happen with bump in program version number.

Yes, definitely! It is not too bad if the new procedures are added in 
the end, and a new build is run only on the server. However, there will 
be compatibility issues if
- the new procedures are added in the middle, OR
- the new procedures are only available in the build on the client

Adding them in the end instead of the middle makes it easier to read 
traffic captures. It is very confusing to see the procedure-number 
change between protocol-versions. In this case, I wanted to add the new 
procedures to Wireshark, where I noticed this incompatibility. The 
enumerations are copied to one of the headers there, merging them made 
me start this email thread.

Oh, and if the version of the protocol increases, try to put me as 
a reviewer on the patch or let me otherwise know. It's one of the things 
Wireshark has to get taught.

Thanks,
Niels