Open Stack

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

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.

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


You're saying that you're assuming the topic is an exchange, and allowing the queue name to be something else?  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?

Regards,
Eric Windisch