[openstack-dev] AMQP Version upgrade plans?

Ted Ross tross at redhat.com
Mon Jul 8 14:51:55 UTC 2013

On 06/24/2013, Russell Bryant wrote:
> On 06/24/2013 02:01 PM, Sunjeet Singh wrote:
> >/  
/> >/  OpenStack currently uses AMQP 0.8. Are there any plans to upgrade?
> OpenStack is not specifically tied to an AMQP version.  It's more about
> what clients we have support for, what versions they speak, and then
> what message brokers support that.
> Right now we have support for using the kombu (for RabbitMQ) and qpid
> (for Qpid) clients.
> I actually have a big interest in adding support for AMQP 1.0.  One of
> the *really* interesting things with AMQP 1.0 that is relevant for
> OpenStack is that it is not tied to using a message broker.  You can use
> it in both a peer-to-peer and a brokered way.  This is interesting,
> because depending on the messaging pattern we're using, we may want one
> vs the other in different parts of OpenStack.
> As for the specifics to doing this, the only AMQP 1.0 client I know of
> is Proton.  It does have Python bindings.
> As for the server side, ActiveMQ recently added AMQP 1.0 support using
> this same library (proton).
> --
> Russell Bryant

AMQP 0-{8,9,10} are asymmetric client/server protocols with a 
well-defined server/broker behavior. AMQP 1.0, by contrast, is a 
symmetric wire-line protocol, without a requirement for a broker at 
all.  As Russell points out, this opens the possibility of brokerless 
peer-to-peer messaging.

The problem with peer-to-peer at the transport is that it doesn't scale 
well, doesn't provide fanout, requires complicated URL management, and 
causes problems with firewalls.  It might be appropriate for a small 
number of use cases, but a broker or some other form of intermediary is 
still needed.

There is a sub-project of Apache Qpid, built on the Proton libraries, 
called Qpid Dispatch.  Dispatch is a lightweight intermediary that is 
not a broker but can be used to build a messaging bus that provides 
peer-to-peer and peer-to-multi-peer connectivity at the messaging level 
(i.e. based on messaging addresses, not host/port urls).  It can also be 
used to provide connectivity to brokers for the cases where brokers are 
necessary (persistent store-and-forward for example).

If someone from the Qpid community were to work on integrating the new 
AMQP 1.0 technology into OpenStack, where would be the right place to 
start?  Would it be to add a new transport to oslo.messaging?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130708/8ecca350/attachment.html>

More information about the OpenStack-dev mailing list