On 11/17/2013 01:57 PM, Steve Baker 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)
A separate process can be autoscaled independently of heat-api which is
a big plus architecturally.
They really do different things, and separating their concerns at the
process level is a good goal.
I prefer a separate process for these reasons.
Regards
-steve
What do you think?
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
