Open Stack

----- Original Message -----
> 
> 
> ----- 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 t
> others?

Actually rereading this I think it does. i.e. the first example is essentially fanout=false.

William

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