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