[openstack-dev] [Oslo] First steps towards amqp 1.0

Gordon Sim gsim at redhat.com
Tue Dec 10 12:15:01 UTC 2013

On 12/09/2013 11:29 PM, Mark McLoughlin wrote:
> On Mon, 2013-12-09 at 16:05 +0100, Flavio Percoco wrote:
>> Greetings,
>> As $subject mentions, I'd like to start discussing the support for
>> AMQP 1.0[0] in oslo.messaging. We already have rabbit and qpid drivers
>> for earlier (and different!) versions of AMQP, the proposal would be
>> to add an additional driver for a _protocol_ not a particular broker.
>> (Both RabbitMQ and Qpid support AMQP 1.0 now).
>> By targeting a clear mapping on to a protocol, rather than a specific
>> implementation, we would simplify the task in the future for anyone
>> wishing to move to any other system that spoke AMQP 1.0. That would no
>> longer require a new driver, merely different configuration and
>> deployment. That would then allow openstack to more easily take
>> advantage of any emerging innovations in this space.
> Sounds sane to me.
> To put it another way, assuming all AMQP 1.0 client libraries are equal,
> all the operator cares about is that we have a driver that connect into
> whatever AMQP 1.0 messaging topology they want to use.
> Of course, not all client libraries will be equal, so if we don't offer
> the choice of library/driver to the operator, then the onus is on us to
> pick the best client library for this driver.

That is a fair point. One thing to point out about Qpid proton is that 
it is in fact two different things in the one library. On the one hand 
it is a fully fledged client library with its own IO and model of use. 
On the other hand it has a passive protocol engine that is agnostic as 
to the IO/threading approach used and merely encapsulates the encoding 
and protocol rules. This allows it to be integrated into different 
environments without imposing architectural restrictions.

My suggestion would be to use the protocol engine, and design the IO and 
threading to work well with the rest of the oslo.messaging code (e.g. 
with eventlet or asynchio or whatever). In some ways this makes 
oslo.messaging a client library in its own right, with and RPC and 
notify based API and ensuring that other choices fit in well with the 
overall codebase.

More information about the OpenStack-dev mailing list