OK, get that so far - so both consumers need to declare and use the same exchange.
But If I understand the next step right, to get multiple consumers of info notification messages they would all need to create separate "notifications.info" queues into that exchange. And isn't that exactly what Nova currently does to create a shared queue ? Phil From: Kiall Mac Innes [mailto:ki...@managedit.ie] Sent: 09 May 2012 10:51 To: Day, Phil Cc: openstack@lists.launchpad.net; Russell Bryant; Doug Hellmann Subject: Re: [Openstack] [nova] why does notification use a "topic" exchange instead of "fanout"? Your own queue listener should attempt to declare the exchange, using the same settings as Nova does. If the exchange exists, its a noop. Otherwise it's created for you. After that, if you start up Nova, it will do the same and reuse your exchange. Obviously this works both ways, and either nova or your code can declare the exchange. AMQP is designed to be a configuration-less protocol, where resources are configured by the first consumer attempting to use them. Thanks, Kiall Sent from my phone. On May 9, 2012 9:52 a.m., "Day, Phil" <philip....@hp.com<mailto:philip....@hp.com>> wrote: Hi Doug, > I think you missed my main point, which was that a topic exchange does > not impose a limitation that only one client can consume a given > notification. That's only true if each client is consuming from the > same queue bound to the exchange. So just to be clear, if I understand you correctly within the nova service/rpc abstraction layers the code is set up so that all services do bind to the same queue, and hence we get the round-robin delivery. But, if someone wanted to write a separate notification consumer so that they didn't block anyone else from seeing the same messages then they (the consumer) should create a new queue on the existing topic exchange. Is that correct - and is there any worked example of doing this ? I thought within the nova code both the exchange and topic queues were set up by the consumer (so for example all compute_managers try to create the "compute" exchange and topic queue, but its only created by the first one and the others connect to the same queue). In that context I'm finding it hard to see how to change this model to have multiple "notify.info<http://notify.info>" topic queues into the same exchange ? Cheers, Phil From: openstack-bounces+philip.day=hp....@lists.launchpad.net<mailto:hp....@lists.launchpad.net> [mailto:openstack-bounces+philip.day<mailto:openstack-bounces%2Bphilip.day>=hp....@lists.launchpad.net<mailto:hp....@lists.launchpad.net>] On Behalf Of Doug Hellmann Sent: 08 May 2012 23:34 To: Russell Bryant Cc: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Subject: Re: [Openstack] [nova] why does notification use a "topic" exchange instead of "fanout"? On Tue, May 8, 2012 at 6:04 PM, Russell Bryant <rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote: On 05/08/2012 05:59 PM, Doug Hellmann wrote: > Here is a relevant section pulled out of the amqp 0-9-1 spec: > > 3.1.3.3 The Topic Exchange Type > > The topic exchange type works as follows: > > 1. A message queue binds to the exchange using a routing > pattern, P. > 2. A publisher sends the exchange a message with the routing > key R. > 3. The message is passed to the message queue if R matches P. > > The routing key used for a topic exchange MUST consist of zero or > more words delimited by dots. Each word may contain the letters A-Z > and a-z and digits 0-9. > > The routing pattern follows the same rules as the routing key with > the addition that * matches a single word, and # matches zero or > more words. Thus the routing pattern *.stock.# matches the routing > keys usd.stock and eur.stock.db but not stock.nasdaq. > > In nova, for a given topic such as 'scheduler', all of the consumers are > binding to the same queue on the topic exchange, resulting in > round-robin delivery to each of the consumers. If instead you make a > new queue, you can get your own copy of each message. > > There is an additional benefit of using a topic exchange here. The > topic used for notifications is 'notifications.<priority>'. That means > that when you create your queue, you can set it up to receive all > notifications, or only notifications of a certain priority. > > > Topic exchanges make a lot of sense for messages that should only be > consumed once, such as tasks. Notifications are different. Lots of > different clients might want to know that some event happened in the > system. The way things are in Nova today, they can't. The first client > who consumes a notification message will prevent all of the other > clients from seeing that message at all. I think you missed my main point, which was that a topic exchange does not impose a limitation that only one client can consume a given notification. That's only true if each client is consuming from the same queue bound to the exchange. Yes, that wasn't obvious from any of the kombu documentation I've seen so far. I'll keep looking. Thanks, Doug > I can change Nova's notification system to use a fanout exchange (in > impl_kombu.py changing the exchange type used by NotifyPublisher), but > before I submit a patch I want to make sure the current implementation > using a topic exchange wasn't selected deliberately for some reason. I think using a fanout exchange would be a downgrade. As I mentioned before, a topic exchange allows you to create a queue to get all notifications or only notifications of a specific priority. If the exchange type is changed to fanout, it's everybody gets everything, and that's it. -- Russell Bryant _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
