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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
