[openstack-dev] [Heat] rough draft of Heat autoscaling API
sbaker at redhat.com
Mon Nov 18 08:50:55 UTC 2013
On 11/18/2013 01:03 PM, Christopher Armstrong wrote:
> On Sun, Nov 17, 2013 at 2:57 PM, Steve Baker <sbaker at redhat.com
> <mailto: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
> > 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
> to the existing heat-api endpoint.
> Arguments for just making auto scaling part of heat api include:
> * Significantly less development, packaging and deployment
> 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
> 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
> * 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 endpoint?
I have no preference here. It is currently mostly inside /groups/
anyway, this seems like a reasonable base path.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev