> On 11/10/2013 11:53 PM, John Dickinson wrote: > > A random off-the-top-of-my-head use case would be to subscribe to > > events from creating or changing objects in a particular Swift > > account or container. This would allow much more efficient listings > > in Horizon for active containers (and may also be consumed by other > > listeners too). > > > > --John > > > > yupp. > There are many many usecases for this, and we'd get rid of pulling > services for status.
Sounds reasonable, but just one caveat ... Notifications can either be disabled in the service config (e.g. by setting the notifier_strategy to noop in the glance config) or mis-configured (e.g. by not overriding control_exchange name in the cinder code) such that the notifications are not seen by the consumer. We have a similar potential problem with ceilometer, and no good way currently of detecting the non-flow of notifications, i.e. the old story that the absence of evidence <> evidence of absence. I'm not sure whether if it would be workable for horizon to detect whether notifications are flowing for each service by probing in some way (e.g. by setting & unsetting a random property on an image and then ensuring that the corresponding image.update events are seen). If the absence of notifications were easily & reliably detectable, then obviously horizon could simply fallback to polling. Anyhoo, just some food for thought. Cheers, Eoghan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev