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 option. Matthias _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev