Open Stack

----- Original Message -----
> 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.

This really helps understand some of what I've read. Thanks. 

It seems that exchange is really just a high level qualifier of a namespace for the most part.

Q: if in the above last Target, fanout was false (fanout=False) would that mean that you are expecting queue type behavior in that instance? i.e. I want only one consumer, I don't care which one, but only one consumer to service this request? So that syntax would change the semantics from pub/sub topic (i.e. all subscribers to the topic get it) to a queue semantic (first consumer to acquire the message causes it to dequeue and be not available to others?

William

> 
> Cheers,
> Mark.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>