Open Stack

On Tue, Jan 29, 2013 at 11:54 AM, Eric Windisch <eric at cloudscaling.com>wrote:

> This is fairly moot if this feature is tied to the new messaging envelope,
> however. Sending from NEW->OLD simply won't work if the envelope is
> enabled. (Note, Russell has put some effort into making the envelope
> cross-version compatible, but I have some concerns about that tied to my
> previous email regarding the envelope format as it stands today)
>

This change is not tied to the new messaging envelope.  At one point, I
thought the change might make use of the envelope, but the envelope won't
fully be supported until after Grizzly and my thoughts on using it are a
little controversial anyway as well as require a change to it.  As is, I'm
pretty sure the envelope would either allow the downlevel RPC or not.  I
want something that allows the RPC if in compatibility mode and fail the
RPC if not.


> Assuming there is no new envelope… We've discussed it already, but I'm
> still unclear why the old queue cannot be, for the duration of a single
> release, ALSO be consumed by the caller?
>
> The OLD system sends the message somewhere and the NEW system knows where
> it is being sent to, it is just refusing to pick it up. That is, besides
> the impact on performance, why not ALWAYS use the new method while
> retaining the ability of the old pattern to continue functioning if this is
> a choice? Given a no-backwards-compat configuration flag, or an upgrade to
> H, this consumer could be disabled for a performance benefit.  Basically,
> support both and deprecate the old.
>

We have discussed this and I'm not communicating it well.  I wonder if you
are mixing up the queues for receiving the call with the queues for
receiving the response to the call.  Let me try this notation:

All these will work and will not require any more than one queue for the
response, which in all but one case is the old style queue:

   - NEW(compat)->NEW(compat)
   - OLD->NEW(compat)
   - NEW(compat)->OLD
   - NEW(fast)->NEW(compat) : Note in this case, the compat mode code
   recognizes the new information in the message and response appropriately
   (in the new way)
   - NEW(compat)->NEW(fast)


This is the only case that will have the problem of loosing the RPC call
reply.  We cannot listen on two queues for the response since we want
NEW(fast) to be fast.

   - NEW(fast)->OLD


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