Open Stack

On Mon, Jan 28, 2013 at 1:38 PM, Russell Bryant <rbryant at redhat.com> wrote:

> That's pretty much how all of the rpc internal API backwards
> compatibility has been handled so far.  We've got versioning on the
> APIs, but no real intention to maintain compatibility beyond N-1.  The
> code gets messy enough maintaining backwards compatibility just 1
> release back.  The eventual goal is to allow rolling upgrades from
> release to release.  If you need to go to N+2, you either don't do a
> live upgrade or you go through N+1 first.
>

Thank you, I feel better that this has been thought about.  Of course,
everything can be improved upon.  This is the second part of my proposal:
fail an RPC if the envelope includes foreign keys.  This could be used to
add a feature in the release it was conceived, instead of waiting for two
releases, as follows:

   - Release N has a new feature.
   - It identifies it's new feature with a new key in the RPC envelope it
   sends on each request
   - When and RPC call is made to an older version, the older version
   returns a version mismatch error since it does not recognize the foreign
   key.
   - The RPC is immediately re-issued in a compatible way, without the
   foreign key.

The consequence is downlevel RPCs require two calls so are very inefficient
but do suceed.  This does not preclude the two release method.  It just
provides more options.

Just a thought

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130129/87cf1a79/attachment.html>