Open Stack

On 01/26/2013 12:35 PM, Ray Pekowski wrote:
> On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <pekowski at gmail.com
> <mailto:pekowski at gmail.com>> wrote:
> 
>     Otherwise new non-backward compatible changes would need to go
>     through two releases.  The first for the option to be recognized but
>     disabled and a second for it to actually be enable, just as being
>     done for the RPC envelope.  With my proposal, we can skip the
>     recognizing release, since by definition an unknown entry in the
>     envelope is recognized as a failure.
> 
> 
> Is this two release approach for non-backward compatible RPC protocol
> changes even acceptable?  The RPC envelope change
> (https://blueprints.launchpad.net/oslo/+spec/version-rpc-messages) is in
> the first part of this two release approach.  It makes Grizzly RPC aware
> of envelopes, but does not use them.  I think this approach will limit
> release migrations to N-1, at least if part of the migration includes
> coexistence of releases.  Is it true we never plan to migrate from
> anything older than the previous release?
> 
> Once the RPC envelope change hits the H release and it is enabled,
> without some other change, the H level RPCs will only be able to
> communicate with Grizzly and greater, not Folsom, not Essex, etc.  I'm
> just wondering if this is such a good idea.

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.

-- 
Russell Bryant