[openstack-dev] [Heat] rough draft of Heat autoscaling API

Christopher Armstrong chris.armstrong at rackspace.com
Mon Nov 18 00:03:56 UTC 2013

On Sun, Nov 17, 2013 at 2:57 PM, Steve Baker <sbaker at redhat.com> wrote:

> On 11/15/2013 05:19 AM, Christopher Armstrong wrote:
> > http://docs.heatautoscale.apiary.io/
> >
> > I've thrown together a rough sketch of the proposed API for
> > autoscaling. It's written in API-Blueprint format (which is a simple
> > subset of Markdown) and provides schemas for inputs and outputs using
> > JSON-Schema. The source document is currently
> > at https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp
> >
> Apologies if I'm about to re-litigate an old argument, but...
> At summit we discussed creating a new endpoint (and new pythonclient)
> for autoscaling. Instead I think the autoscaling API could just be added
> to the existing heat-api endpoint.
> Arguments for just making auto scaling part of heat api include:
> * Significantly less development, packaging and deployment configuration
> of not creating a heat-autoscaling-api and python-autoscalingclient
> * Autoscaling is orchestration (for some definition of orchestration) so
> belongs in the orchestration service endpoint
> * The autoscaling API includes heat template snippets, so a heat service
> is a required dependency for deployers anyway
> * End-users are still free to use the autoscaling portion of the heat
> API without necessarily being aware of (or directly using) heat
> templates and stacks
> * It seems acceptable for single endpoints to manage many resources (eg,
> the increasingly disparate list of resources available via the neutron API)
> Arguments for making a new auto scaling api include:
> * Autoscaling is not orchestration (for some narrower definition of
> orchestration)
> * Autoscaling implementation will be handled by something other than
> heat engine (I have assumed the opposite)
> (no doubt this list will be added to in this thread)
> What do you think?
I would be fine with this. Putting the API at the same endpoint as Heat's
API can be done whether we decide to document the API as a separate thing
or not. Would you prefer to see it as literally just more features added to
the Heat API, or an "autoscaling API" that just happens to live at the same

IRC: radix
Christopher Armstrong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131117/fde409df/attachment.html>

More information about the OpenStack-dev mailing list