[openstack-dev] [Heat] How the autoscale API should control scaling in Heat

Joshua Harlow harlowja at yahoo-inc.com
Thu Sep 12 07:57:36 UTC 2013


Cool, thanks for the explanation and clarification :)

Sent from my really tiny device...

On Sep 12, 2013, at 12:41 AM, "Steven Hardy" <shardy at redhat.com> wrote:

> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list