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.
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
