Open Stack

On Tue, Jan 29, 2013 at 3:39 PM, Eric Windisch <eric at cloudscaling.com>wrote:

> My point was that by listening on two queues and not changing msg_id, you
> can send messages in fast-mode and receive in both modes. Then, Grizzly
> will be able to send and reply and get replies from Havana, regardless of
> if Grizzly is set to compatibility mode or not. Grizzly would also, by
> default, be able to send and reply to Folsom, as well as receive replies
> from Folsom as long as compatiblity mode is not disabled.


I think I finally see your point.  Instead of the compatibility mode
changing the way the message is sent (old way vs new way), compatibility
mode could determine whether to wait on one or two queues.  Yes, I do
believe that would work, but there are a few reasons why it is not a good
idea:

   - It would be more lines of code.
   - It would significantly change the legacy code that listens on the old
   queue.

Although those aren't good enough reasons on their own, they do add risk to
the change.  It makes it easier to introduce bugs.

Probably the best reason is the existing change can do all the things you
mentioned:

   1. "Grizzly will be able to send and reply and get replies from Havana,
   regardless of if Grizzly is set to compatibility mode or not"
   This can be accomplished by retaining in Havana the code that recognizes
   the old message content and replies in the old way if found.

   2. "Grizzly would also, by default, be able to send and reply to Folsom,
   as well as receive replies from Folsom as long as compatibility mode is not
   disabled."
   This is by design.

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