Open Stack

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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev