openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Tue, May 8, 2012 at 5:45 PM, Russell Bryant <rbryant@xxxxxxxxxx> wrote:

> On 05/08/2012 04:19 PM, Doug Hellmann wrote:
> > I'm working on some code to monitor notification messages coming from
> > nova by listening directly on the AMQP queue. Unfortunately, nova is
> > using a topic exchange so it seems I can't safely consume the messages
> > or they might not go to some other client that is expecting to see them
> > (especially some other part of nova that is expecting to receive the
> > notification). It seems like notifications should be available to more
> > than one subscriber at a time, but I thought I would ask for background
> > before I started working on a patch to change it.
> >
> > Is there a particular reason a topic exchange was used for notifications?
>
> I believe you can still get what you want (but not by using nova.rpc as
> your client).
>

I'm not using nova.rpc in my code. I am using kombu to connect to the
rabbit queue directly.


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