Open Stack

Hi William,

I think Doug has done a good job of answering all these, but here's
another set of answers to make sure there's no confusion :)

On Fri, 2013-07-12 at 17:40 -0400, William Henry wrote:
> Hi all, 
> 
> I've been reading through the Messaging Wiki and have some comments.

The docs generated from the code are now up on:

  http://docs.openstack.org/developer/oslo.messaging/

There should be some useful clarifying stuff in there too. Indeed some
of thinking has moved on a bit since the wiki page was written.

>  Not criticisms, just comments and questions. 
> I have found this to be a very useful document. Thanks. 
> 
> 1. "There are multiple backend transport drivers which implement the
> API semantics using different messaging systems - e.g. RabbitMQ, Qpid,
> ZeroMQ. While both sides of a connection must use the same transport
> driver configured in the same way, the API avoids exposing details of
> transports so that code written using one transport should work with
> any other transport." 
> 
> The good news for AMQP 1.0 users is that technically "boths sides of
> the connection" do not have to use same transport driver. In pre-AMQP
> 1.0 days this was the case. But today interoperability between AMQP
> 1.0 implementations has been demonstrated. 

Yeah, the point was more that like you need to use the zmq driver on
both sides.

I could imagine us having multiple "amqp 1.0" interoperable drivers. I
don't know what the use case would be for using one of those drivers on
one side and another on the other side, but there's no reason why it
should be impossible.

> 2. I notice under the RPC concepts section that you mention Exchanges
> as a container in which topics are scoped. Is this exchange a pre AMQP
> 1.0 artifact or just a general term for oslo.messaging that is loosely
> based on the pre-AMQP 1.0 artifact called an Exchange? i.e. are you
> assuming that messaging implementations have something called an
> exchange? Or do you mean that messaging implementations can scope a
> topic and in oslo we call that scoping an exchange? 

Yeah, it really is only loosely related to the AMQP concept.

It's purely a namespace thing. You could e.g. have two Nova deployments
with exactly the same messaging transport (and e.g. sending messages
over the same broker, using the same topic names, etc.) and you could
keep them separated from one another by using a different exchange name
for each.

The reason we've stuck with the name "exchange" is that we have a
"control_exchange" configuration variable (defaulting to e.g. 'nova')
that servers roughly this purpose now and we want to continue using it
rather than renaming it to something else.

Which raises a point about all of this - we need to be able to
interoperate with existing OpenStack deployments using the current RPC
code. So, we really don't have the luxury of changing on-the-wire
formats, basic messaging semantics, configuration settings, etc.

oslo.messaging is mostly about cleaning up the python API which services
use to issue/receive RPCs and send notifications.

> 3. Some messaging nomenclature: The way the wiki describes RPC "
> Invoke Method on One of Multiple Servers " is more like a queue than a
> topic. In messaging a queue is something that multiple consumers can
> attach to and one of them gets and services a message/request. A topic
> is where 1+ consumers are "connected" and each receives a the message
> and each can service it as it sees fit. In pre-AMQP 1.0 terms what
> this seems to describe is a direct exchange. And a direct excahnge can
> have multiple consumers listening to a queue on that exchange.
> (Remember that fanout is just a generalization of topic in that all
> consumers get all fanout messages - there are no sub-topics etc.) 
> 
> In AMQP 1.0 the addressing doesn't care or know about exchanges but it
> can support this queue type behavior on an address or topic type
> behavior on an address. 
> 
> I know this isn't about AMQP specifically but therefore this is even
> more important. Topics are pub/sub with multiple consumer/services
> responding to a single message. Queues are next consumer up gets the
> next message. 
> 
> (BTW I've seen this kind of confusion also in early versions of
> MCollective in Puppet.) 
> 
> It might be better to change some of the references to "topic" to
> "address". This would solve the problem. i.e. a use case where one of
> many servers listening on an address services a message/request. And
> later all of servers listening on an address service a
> message/request. Addressing also solves the one-to-one as the address
> is specific to the server (and the others don't have to receive and
> reject the message).

It sounds to me like the qpid-proton based transport driver could easily
map the semantics we expect from topic/fanout to amqp 1.0 addresses.

The 'topic' nomenclature is pretty baked in the various services doing
RPC and notifications, especially in the naming of configuration
options.

The basic semantics is a nova compute service listens on the 'compute'
topic on the 'nova' exchange and a client can cause a method to be
invoked on the service with either of the following targets:

  Target(exchange='nova', topic='compute')
  Target(exchange='nova', topic='compute', server='compute1')
  Target(exchange='nova', topic='compute', fanout=True)

In the first case, any compute service will do. In the second, you want
to invoke the method on a particular compute service. The the latter
case, you want to invoke it on all compute services.

Cheers,
Mark.