Open Stack

On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130126/dd3fa763/attachment.html>