<br><br><div class="gmail_quote">On Thu, Sep 6, 2012 at 12:25 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> We needed something like declare_topic_consumer() in ceilometer and I couldn't find another way to listen to notifications without using the AMQP libraries directly. It's on my list of things to add to the RPC library, but I'm still working on getting ceilometer working end-to-end, so I haven't started circling back and "fixing" stuff like this, yet. I hope to have more of that done in grizzly.<br>

><br>
<br>
</div>Right. The question is: does Quantum change what it is doing to follow a standard pattern, as you have, or do we add something like declare_topic_consumer() to the abstraction?  I'm thinking the latter might be a good thing to have, regardless. I acknowledge this would require implementation of this in the ZeroMQ driver and I realistically can't expect this to land in Folsom.  In a way, changing the Quantum behavior is easier to scope.<br>
</blockquote><div><br></div><div>I agree the right way to fix this from a design perspective is to update the abstraction. I can't speak for the level of work needed to change Quantum or update ZeroMQ.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
> I'm not sure what you mean about removing the queue name argument. That's there so the client can indicate which messages it wants. Do you have in mind another way to do that?<br>
><br>
<br>
<br>
</div>You're saying that you're assuming the topic is an exchange, and allowing the queue name to be something else?</blockquote><div><br></div><div>That's how it works for AMQP. Several workers join the same queue so that only one of them receives a given message. The topic controls the messages sent to that queue. Multiple worker pools can use different queue names so that each pool receives a copy of the message. That allows the same horizontal-scaling pattern as the declare_worker() method does for full RPC messages and is a critical part of the design of ceilometer, where we are expecting to be processing a large number of messages with a pool of several collector daemons.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I can see the value in that, especially in the private methods.  I'd still be inclined to starting with a generalized declare_topic_consumer() being without a queue_name argument in a first-pass, it is far less complex.  Long-term, this needs to be handled by the MatchMaker and the ServiceGroupAPI - at least in the ZeroMQ driver - much of which won't land until Grizzly.  The generalized form could pass into the more flexible (but private) declare_topic_consumer() in the case of Kombu and RabbitMQ.  Later in Grizzly, if we can evolve the matchmaker and ServiceGroupAPI sufficiently, then we might add an equivilent to the queue_name argument to the generalized form.  I hope this is reasonable?<br>
</blockquote><div><br></div><div>It's fine to update the method argument names to improve the abstraction, but we need both arguments to be passed separately for the method to be useful in ceilometer.</div><div><br></div>
<div>Is there documentation for the MatchMaker or ServiceGroupAPI somewhere? I've seen them mentioned before, but gather that they are relatively new and I haven't had a chance to dig into them at all.</div><div><br>
</div><div>Doug</div><div><br></div></div>