Open Stack

On Thu, Sep 12, 2013 at 04:15:39AM +0000, Joshua Harlow wrote:
> Ah, thx keith, that seems to make a little more sense with that context.
> 
> Maybe that different instance will be doing other stuff also?
> 
> Is that the general heat 'topology' that should/is recommended for trove?
> 
> For say autoscaling trove, will trove emit a set of metrics via ceilometer
> that heat (or a separate autoscaling thing) will use to analyze if
> autoscaling should occur? I suppose nova would also emit its own set and
> it will be up to the autoscaler to merge those together (as trove
> instances are nova instances). Its a very interesting set of problems to
> make an autoscaling entity that works well without making that autoscaling
> entity to aware of the internals of the various projects. Making it to
> aware and then the whole system is fragile but not making it aware enough
> and then it will not do its job very well.

No, this is not how things work now we're integrated with Ceilometer
(*alarms*, not raw metrics)

Previously Head did do basic metric evaluation internally, but now we rely
on Ceilometer to do all of that for us, so we just pass a web-hook URL to
Ceilometer, which gets hit when an alarm happens (in Ceilometer).

So Trove, Nova, or whatever, just need to get metrics into Ceilometer, then
you can set up a Ceilometer alarm via Heat, associated with the Autoscaling
resource.

This has a number of advantages, in particular it removes any coupling
between heat and specific metrics or internals, and it provides a very
flexible interface if people want to drive Heat AutoScaling via something
other than Ceilometer (e.g the autoscale API under discussion here)

Steve