Open Stack

On 5 April 2013 11:07, Alan Kavanagh <alan.kavanagh at ericsson.com> wrote:
> The reason I see a need to separate it is because you "may have external system" that can be responsible for "doing the policy decision" of when and based on what to call for a given service type to be auto-scaled. Even if you have LB running on bare metal you for sure do not need to use HEAT for being the one to handle the auto-scale request.......if you do see it like that......then lets discuss why it "MUST BE THIS WAY".  For sure HEAT can do this, but its must not create a dependence that when a given service such as LB requires auto-scaling that it must be done through HEAT......as I still don't see why folks are mandating this.
>
> To me, you would get some event notification coming from the LB and this is feed into some central collector agent. This then has an interface to a Policy Rule Engine that takes this input and based on say given SLA parameters will decide to auto-scale. This can then call the appropriate controllers (NOVA+Quantum) to provision, configure and deploy accordingly. This does NOT require that you call the HEAT API.
>
> If you have another way to do it "simpler and efficient Robert" then put it on the table.

Well I'm trying to understand the concerns. Is the concern that you
want to be able to replace the policy rule engine? Or that you want a
rule engine with lots of different rules?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services