Cool, thanks for the explanation and clarification :) Sent from my really tiny device...
On Sep 12, 2013, at 12:41 AM, "Steven Hardy" <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
