[openstack-dev] Horizon PTL candidacy

Matthias Runge mrunge at redhat.com
Tue Nov 12 11:25:57 UTC 2013

On 11/12/2013 12:09 PM, Eoghan Glynn wrote:
> 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.
Thank you for your input here.

That is true, we'd rely on an additional service, whether marconi or
some oslo service doesn't matter in first place here. The service may
not be accessible or even not reliable; we might miss messages, and
simply trusting in getting messages in the right order etc. is probably
not a stable approach here. A fallback to pulling again is definitely an


More information about the OpenStack-dev mailing list