<div>ceilometer is going to need to subscribe several worker processes</div><div>to the <a href="http://notifications.info">notifications.info</a> topic for the other services like nova,</div><div>glance, and quantum. The pool of workers needs to be assured of</div>
<div>receiving all messages, without interference from other clients</div><div>listening for notifications (such as metering, audit logging,</div><div>monitoring, etc.).</div><div><br></div><div>The drivers implement create_consumer() for topic consumers by</div>
<div>always making the topic and queue name the same. That supports</div><div>the consumer patterns we have encountered so far, but does not</div><div>allow for load balancing between workers as we want for the</div><div>
ceilometer collector.</div><div><br></div><div>The fanout argument is used by the existing drivers to control</div><div>the breadth of distribution. With fanout=True, every consumer</div><div>receives a copy of the event because every consumer has its own</div>
<div>queue. This gives us no load balancing benefit for having</div><div>multiple consumers. With fanout=False only one consumer *at all*</div><div>will get a copy of the event, since they all listen on the same</div><div>
queue. This means if metering, audit logging, and monitoring are</div><div>all listening for notifications they will each see only some of</div><div>the events.</div><div><br></div><div>The way to achieve load balancing is to have the ceilometer</div>
<div>consumers connect to the same exchange and topic using a shared,</div><div>well-known, queue name that is different from the name used</div><div>by non-ceilometer consumers.  Unfortunately, the only parameter that</div>
<div>cannot be controlled by the caller of create_consumer() is the</div><div>queue name.</div><div><br></div><div>I have a patch ready for review [1] to add a new method,</div><div>create_worker() to the RPC Connection class, to allow a group of</div>
<div>consumer to share a queue to manage load.  The worker pool allows</div><div>multiple consumers to receive a given message (by subscribing to</div><div>separate queues), but it also allows several consumers to declare</div>
<div>that they are collaborating so that only one of the subset</div><div>receives a copy (by subscribing to the same queue). That means</div><div>that multiple "types" of consumers can be listening to</div><div>
notifications and each type of consumer can have a load balanced</div><div>pool of workers so that messages are only processed once for that</div><div>type (once for metering and once for logging, for example).</div><div>
<br></div><div>Two separate implementations were discussed: Adding</div><div>a "queue_name" argument to create_consumer() and creating a new</div><div>method "create_worker()".  After considering both options, I</div>
<div>chose to add a new method because it clarified the right way to</div><div>combine the inputs to set up workers (fanout must always be true</div><div>and the queue name must always be provided).</div><div><br></div><div>
The code is up for review, so please have a look and let me know</div><div>what you think.</div><div><br></div><div>Doug</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/7590/">https://review.openstack.org/#/c/7590/</a></div>
<div><br></div>