[openstack-dev] Rackspace Plans Contributions to HEAT

Clint Byrum clint at fewbar.com
Fri Apr 5 16:29:38 UTC 2013


Excerpts from Alan Kavanagh's message of 2013-04-05 04:56:07 -0700:
> I want the "flexibility" to choose how I do auto-scaling without having to say it must be done through HEAT. I want the flexibility to have auto-scaling as a service done on top of Openstack not through HEAT API Calling Openstack API's. If you can explain the technical merit and benefit of such a case we can take it from their, as right now all I see is adding another layer on top of another layer etc.......and the benefit to me as an openstack consumer and user is ?

Heat is just an engine for orchestration. If you take "Heat" out of
what you said (it really isn't an acronym and should not be in all caps)
and replace it with "an orchestration service", your sentence is a lot
easier to understand. However, clarity of what you mean also makes it
less clear *why* you want this.

"I want the 'flexibility' to choose how I do auto-scaling without having
to say it must be done through an orchestration service. I want the
flexibility to have auto-scaling as a service done on top of Openstack
not through an orchestration service API calling OpenStack API's."

An orchestration service seems a quite appropriate place to be doing
auto-scaling. Unlike every other component of OpenStack, an orchestration
service is meant to manage all of the OpenStack APIs and keep the
components informed of each other. Quantum's LBaaS will only know
about load balancers. Its coupling to Nova is at the bare minimum, just
enough to get the load balancer to talk to the right servers. However,
an orchestration service also knows about volumes. So when you auto-scale
and need a new volume.. are you going to teach Quantum how to define a
volume and attach it to the instances?

No, I understand you're suggesting auto-scaling should be
separate. However, if you have a stand-alone auto-scaler that is not
Heat, now you have two things which are designed to understand how load
balancers, instances, and volumes connect.

> 
> If we are not progressing then I suggest we take this at the Summit, I am more than happy to discuss this in finer details.
> 

Side Note:
It might help if you start quoting messages rather than top posting. Just
an idea. Putting a response next to the thing you are responding to
tends to help the reader know your intended context. I understand that
some email clients don't allow this, but it is really the only way to
keep mailing list conversations from turning into context-free shouting
matches. Anyway, just a suggestion.

--
Clint Byrum
HP Cloud Services



More information about the OpenStack-dev mailing list