Open Stack

>
> And this doesn't make sense:
>
>   Target(exchange='nova', topic='compute', server='compute1', fanout=True)

That isn't strictly true. We aren't using it and I'm not sure why we would
want to use it, but it isn't senseless as you imply.

There should be no reason at present with the old api that someone couldn't
consume a topic "compute.hostname" as a fanout queue. If this doesn't work
with RabbitMQ or Qpid, that is a bug.

Practically, you can have multiple processes consuming the same
topic/exchange on a single server. The Nova scheduler is a good example of
where this works (whether or not it is a good idea).  Two processes on
"host1" can consume exchange "nova" with topic "scheduler". A fanout from
nova-api should reach both processes. If for some reason, "host1" was
explicitly requested, a fanout should still reach both schedulers on
"host1" (but not schedulers on other hosts).

Since we're talking about AMQP 1.0 here, I should note that the necessity
to support multiple processes consuming the same (topic, exchange, server)
grouping is why we have an *-rpc-zmq-receiver process for ZeroMQ's
peer-to-peer messaging construct. Not just for fanout, but also for
queuing. With non-fanout messaging to a specific (topic, exchange, server)
group, messages should be queued and consumed in turn by the various
processes on the host consuming that grouping. The *-rpc-zmq-receiver
process provides the local queuing and fanout for multiple consumers of a
single topic on a server for these reasons. An AMQP 1.0 driver would need
to have a similar process and could leverage some code reuse.

Again, I'm pressed to see where explicit server + fanout would be useful.
 One example might be an in-memory state update between local processes
using something akin to the following target:

     Target(exchange='nova', topic='scheduler', server=CONF.host,
fanout=True)

Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130717/650813ac/attachment.html>