Open Stack

> 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