Open Stack

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

> > Precisely my point. Why does it have to be fast? If the only reason to
> shun compatibility is performance, lets take the performance bite - by
> default. The configuration setting can then just be a toggle that breaks
> NEW(fast)->OLD and restores the performance gains.
>
>
> I should clarify that the idea here is that *by default* we'd have the
> following compability:
>
> 1) Grizzly <=> Folsom
> 2) Grizzly <=> H (assuming H removes compatibility with Folsom)
>
> Where Grizzly performance by default will be non-optimal, but H (or G with
> a no-compat option enabled) can forgo Folsom compatbility for the
> performance benefit.
>
>
I think we are finally on the same page on this.  The confusion I suppose
has been about listening on two reply queues at once.  It isn't necessary
in compatibility mode (replies will only come back on the old queue) and
certainly not wanted for performance reasons in fast mode (replies will
only come back on the new queue).

And I agree the default mode should be compatibility mode in Grizzly and
fast mode in H.  I will also add a TODO to the code as a reminder to make
the change in H.

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