Autoscaling API for Heat

Registered by Duncan McGreggor on 2013-03-20

Heat has done an enormous amount of work towards feature-parity with AWS AutoScaling and CloudWatch. The intent of this session is to discuss what work remains left to be done, to fully explore the scope of that work, and to come to a consensus on a high-level implementation plan.

In particular, there is interest in creating an API for manipulating scaling groups, responding to alerts, scaling up/down, etc. There are many ways an API could be provided, and at least two different places it could live. This session aims to resolve any ambiguities around this.

Ideally, the outcome of these session would be a well-defined approach for 1) any additional implementation needed in Heat, and 2) a plan for creating an autoscaling API that a consensus agrees is the best approach.

This summit discussion should result in several blueprints detailing whatever specific work needs to be done in the course of the coming release cycle.

Blueprint information

Steve Baker
Christopher Armstrong
Christopher Armstrong
Series goal:
Milestone target:
Completed by
Steve Baker on 2013-11-19

Related branches


(shardy) We already do everything described in this BP, see the AutoScalingMultiAZSample example template, description should be updated or this should be marked obsolete

(oubiwann) I've updated the description... it's not immediately clear to me whether the template you mention (this one? does everything outlined in the updated description. Thanks!

(shardy) Please spend some time evaluating our existing AS functionality - we do almost everything mentioned in this BP already (with the exception of the separate AS API, which could be added), so the scope of this BP is too broad - can you work out what features are missing which you require, then raise a separate BP for each bit of missing functionality? (e.g "Add API to Autoscaling"). Drop into #heat so we can discuss your ideas and requirements further, thanks! :)

Resources which implement this functionality:
AWS::AutoScaling::AutoScalingGroup :
implemented in : heat/engine/resources/

implemented in : heat/engine/resources/

implemented in : heat/engine/resources/

implemented in : heat/engine/resources/

The metric collection is currently performed by an in-instance agent (a clone of the cfn-push-stats tool, which pushes metrics to our CloudWatch (heat-api-cloudwatch) API, via cron-jobs in each instance, this is a basic mechanism, which will eventually be replaced or supplemented by ceilometer metrics and alarms, but currently ceilometer monitoring functionality is not complete enough for us to adopt it (see

So as you can see, we already implement a large proportion of what you're proposing, so a more constructive way forward is to evaluate the gaps in our existing implementation, rather than proposing a wholesale replacement with some new service (I understand you're working on something, but we have no visibility of it)

(shardy) Further note re AS API - although I used this as an example, I personally don't see this as a priority, since we support UpdateStack for the AS resources, so the preferred method of manipulating AS resources is by updating your stack template then updating the stack via heat-api or heat-api-cfn. We could certainly add a separate AS API in future, but right now I'm not sure if the effort involved can be justified.

(oubiwann) shardy, thanks SO MUCH for all the detail you provided. Absolutely brilliant. Over the next week, we will be digging into the resources that you have identified and assess functionality against our use cases and then refine the proposed discussion to cover only that which has no overlap with the amazing amount of work that has already been done in Heat. Thanks again for going above and beyond, and so clearly stating the exact points of implementation!

(stevebaker) Obsoleting, I've found the actual autoscaling blueprints


Work Items