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

Steve Baker 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
>     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 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...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/bf631d22/attachment.html>

More information about the OpenStack-dev mailing list