Open Stack

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 24/06/14 09:28, Clint Byrum wrote:
> > Hello! I would like to turn your attention to this specification draft
> > that I've written:
> > 
> > https://review.openstack.org/#/c/100012/1/specs/convergence-continuous-observer.rst
> > 
> > Angus has suggested that perhaps Ceilometer is a better place to handle
> > this. Can you please comment on the review, or can we have a brief
> > mailing list discussion about how best to filter notifications?
> > 
> > Basically in Heat when a user boots an instance, we would like to act as
> > soon as it is active, and not have to poll the nova API to know when
> > that is. Angus has suggested that perhaps we can just tell ceilometer to
> > hit Heat with a web hook when that happens.
> 
> We could have a per-resource webhook (either the signal or something like it)
> that is just a logical notification/kick to go and re-check the resource
> state.
> 
> The other part of this is when we turn on continuous convergence, we could
> get an alarm whenever that resource changes state (or what ever we are
> interested
> in - as long as it is in the notification payload).
> 
> Given the number of resources we want to manage the alarm sub-system will
> need to
> be scalable. I'd rather Ceilometer solve that than Heat.

When we talked about that issue in Atlanta, I think we came to the conclusion that one system wouldn't solve it, and that we need to be able to provide different pluggable solutions.

The first solution is just to move the current polling system and create a generic API around it. That's something that we'll want to keep, even if it's only to make standalone mode works. The next solution for me is to subscribe directly to the notification system. We know the shortcomings, but it's the obvious improvement we can do in the Juno cycle.

Later on, if/when Ceilometer provides what we need, we can implement a new backend using it.

-- 
Thomas