On 11/18/2013 01:03 PM, Christopher Armstrong wrote: > On Sun, Nov 17, 2013 at 2:57 PM, Steve Baker <sba...@redhat.com > <mailto:sba...@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
