<div dir="ltr"><p dir="ltr"><br>
><br>
> And this doesn't make sense:<br>
><br>
>   Target(exchange='nova', topic='compute', server='compute1', fanout=True)</p><p>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.</p>
<p>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.</p><p>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).</p>
<p>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.</p>
<p>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:</p><p>     Target(exchange='nova', topic='scheduler', server=CONF.host, fanout=True)</p>

<p dir="ltr">Regards,<br>
Eric Windisch<br>
</p>
</div>