Open Stack

On 2013-04-03 20:17, Alan Kavanagh wrote:
> This is good news I have to say. Though I have some questions that
> got me irked in reading bullet 4 below on Auto-Scale so im going to
> throw this out for discussion.
> 
> Are we now stating that the HEAT will take care of Auto-Scaling of
> all Openstack Services? If you consider network services managed and
> deployed under Quantum, and if you have Ceilometer collecting event
> notifications then some given "policy engine" would know when to call
> Quantum & || Nova + etc to provision additional resources as needed,
> you do not need to go through HEAT for this. I do see cases where an
> application that is deployed via HEAT would make sense, but for
> services that are inherent and part of the Infrastructure such as LB
> or FW etc I do not see what HEAT would need to handle the scaling for
> these services?
> 

If you look past the current implementation details, and think of Heat 
instead as a way to manage multi-resource relationships, then it makes 
perfect sense for Heat to implement that policy engine. In fact, it 
already has done some of this.

Basically, Heat only has one way to define the necessary policies right 
now, which is a declarative templating system.

However, an API for defining the very same policies in an imperative 
fashion should be really simple to create.

> Agree that Event Trigger and Notification Events must be added to LB
> in order for this to Scale accordingly, I am sure this will come soon
> ;-) in the LBaaS API.
> 

I am somewhat confused by this. I'd like to see auto-scaling separated 
into its own concern. LBaaS is not the only thing that needs to change 
in response to data / config changes.