Open Stack

On 01/24/2013 11:00 PM, Ray Pekowski wrote:
> Regarding blueprint version-rpc-messages
> <https://blueprints.launchpad.net/openstack/?searchtext=version-rpc-messages>,
> I have some thoughts on enhancing it for a backward compatibility
> problem people are having with blueprint amqp-rpc-fast-reply-queue
> <https://blueprints.launchpad.net/openstack/?searchtext=amqp-rpc-fast-reply-queue>
> 
> Here is what I propose and I mention in the code review notes:
> 
> "Perhaps another Grizzly blueprint could be written to augment Russel
> Bryant's version-rpc-messages envelope idea to enabled it by default.
> Today it is disabled with a TODO to enable it after Grizzly. Along with
> this make the necessary changes to detect an RPC failure caused by
> New->Old versions and reissue the RPC without the envelope. Then make my
> blueprint dependent upon that one.

Unfortunately I think there's a fundamental problem with any sort of
solution that requires reissuing messages in a different format after a
failure.  The messaging isn't connection oriented between the sender and
receiver of a given message.  So, just because the last message failed
doesn't mean the next one will.  The version implemented at the other
end can change in between the original and re-sent message.

> And (optionally) perhaps even make a change in the checking of the
> envelope to look for unexpected content in that envelope. For example,
> if we decide in the future to add an implementation version or whatever,
> that a version that supported the envelope, but not the new content
> would fail the RPC."

That's how the envelope works now.  It includes a version number.
Locally we maintain a version number for the latest version that is
supported.  An incoming message lists the minimum version that must be
implemented for the message to be successfully processed.  If that check
fails, an exception will be raised  If it gets updated to include
additional information, the version number will get bumped.

> What do you think?  Does it have problems?

Because of the non-connection oriented issue I mentioned above, I don't
really see a way that we can enable the envelope by default and maintain
the level of compatibility in Grizzly that was intended.

I think we should also try to avoid a new configuration option if at all
possible.  If this new behavior offers better performance, then great,
let's just make it the way it works.

How about we merge a patch today that enables this new behavior at the
same time that message envelopes get turned on.  We can make this
behavior effectively part of the spec for rpc version 2.0 (which is what
is slated to be enabled after Grizzly).

Part of this patch would have to be that it goes ahead and understands
*receiving* messages that want replies to go to a single reply queue and
then being able to send responses there.  We just won't be turning that
on for the sender-side until post-Grizzly.

-- 
Russell Bryant