Here are better links to both blueprints: https://blueprints.launchpad.net/oslo/+spec/version-rpc-messages https://blueprints.launchpad.net/oslo/+spec/amqp-rpc-fast-reply-queue On Thu, Jan 24, 2013 at 10:00 PM, Ray Pekowski <pekowski at gmail.com> 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. > > 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." > > What do you think? Does it have problems? > > I see an advantage. Not only would it work for G to (<G) versions. It > would also work for (>G) to (<G) versions. blueprint > version-rpc-messages > <https://blueprints.launchpad.net/openstack/?searchtext=version-rpc-messages>loses > interoperability with (<G) after Grizzly. Maybe that isn't a valid > concern, but one worth mentioning. > > Ray > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130124/62a8b063/attachment.html>