Open Stack

On 12/09/2013 10:05 AM, 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).

I didn't know the bit about RabbitMQ.  Some clarification to make sure
I understand the picture ...

>From looking it appears that RabbitMQ's support is via an experimental
plugin.  I don't know any more about it.  Has anyone looked at it in
detail?

    https://www.rabbitmq.com/specification.html

As I understand it, "Qpid" supports it, in that it's a completely new
implementation as a library (Proton) under the Qpid project umbrella.
 There's also a message router called Dispatch.  This is not to be
confused with the existing Qpid libraries, or the existing Qpid broker
(qpidd).

    http://qpid.apache.org/proton/
    http://qpid.apache.org/components/dispatch-router/

> 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.
> 
> Since the proposal is not about replacing existing dirvers but
> adding a new one for a specific protocol, there are some things
> that need to be taken under consideration:
> 
> 1. The driver should be developed to work against various 
> implementations of AMQP 1.0.
> 
> 2. The driver shouldn't require support for 'backend-specific' 
> features (Of course a backend specific driver may also be developed
> in the future if desired to exploit some non-standard feature
> etc).
> 
> 3. AMQP 1.0 changed a lot of what we know about AMQP <= 0.10. It's 
> more oriented to messaging rather than queues, brokers and 
> exchanges.
> 
> Some other benefits of unifying backend specific implementations
> under a single protocol based driver are:
> 
> - It'll ease the incorporation of alternatives that emerge and have
> support for such protocol
> 
> - It'll help maintaining the code for that driver and it'll unify 
> efforts throughout the community around that code.
> 
> - It'll help developers to focus more on the benefits of the 
> protocol itself rather than the benefits of that specific driver.
> 
> - It fits perfectly as a non-opinionated feature that embraces 
> existing and emerging technologies through an open standard. - A 
> clear standard wire protocol will make reasoning about partial 
> upgrades/migrations simpler
> 
> That being said. The benefits of having a *protocol* based driver
> does not only apply to AMQP but to any well-defined protocol with a
> wide acceptance. However, AMQP 1.0 seems a reasonable fit right now
> and so a good protocol to begin with.
> 
> Thoughts? Concerns? Ideas?
> 
> [0] http://www.amqp.org/specification/1.0/amqp-org-download

All of this sounds fine to me.  Surely a single driver for multiple
systems is an improvement.  What's not really mentioned though is why
we should care about AMQP 1.0 beyond that.  Why is it architecturally
superior?  It has been discussed on this list some before, but I
figure it's worth re-visiting if some code is going to show up soon.

In the case of Nova (and others that followed Nova's messaging
patterns), I firmly believe that for scaling reasons, we need to move
toward it becoming the norm to use peer-to-peer messaging for most
things.  For example, the API and conductor services should be talking
directly to compute nodes instead of through a broker.  The exception
to that is cases where we use a publish-subscribe model, and a broker
serves that really well.  Notifications and notification consumers
(such as Ceilometer) are the prime example.

In terms of existing messaging drivers, you could accomplish this with
a combination of both RabbitMQ or Qpid for brokered messaging and
ZeroMQ for the direct messaging cases.  It would require only a small
amount of additional code to allow you to select a separate driver for
each case.

Based on my understanding, AMQP 1.0 could be used for both of these
patterns.  It seems ideal long term to be able to use the same
protocol for everything we need.

We could use only ZeroMQ, as well.  It doesn't have the
publish-subscribe stuff we need built in necessarily.  Surely that has
been done multiple times by others already, though.  We could build it
too, if we had to.

Can you (or someone) elaborate further on what will make this solution
superior to our existing options?

Thanks,

-- 
Russell Bryant