On Thu, Aug 1, 2013 at 9:25 AM, Julien Danjou <jul...@danjou.info> wrote:
> On Thu, Aug 01 2013, Sandy Walsh wrote: > > > Right, that is a concern. Within RAX we have two downstream services > > that consume notifications (StackTach and Yagi) and we've configured > > nova to write to two queues. --notifications_topics can take a list. > > Fair enough. So IIUC that means we should change Ceilometer to consume > CONF.notification_topics using the default queue associated with this > topic, and let the deployer add more notification_topics in nova if they > have several consumer (that should have their own > CONF.notification_topics). > > This would be the correct way, even if not really deployer-friendly. > The other solution would be to have the sender of the message NOT declare a queue at all. The queue is a client-side feature, and the sender shouldn't care about the queue. Doug > > > I don't think so, but if that was possible it would solve our problem. > > > > AFAIK, amqp only uses the exchange as a dispatcher and all storage is > > done in the queue ... but I could be wrong. I vaguely recall there being > > a durable exchange setting as well as durable queue. > > > > I'll do some investigating. > > Yeah I've little hope too, but might worth a look. Thanks Sandy! > > -- > Julien Danjou > # Free Software hacker # freelance consultant > # http://julien.danjou.info > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev