Open Stack

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 ?

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.

Alan

-----Original Message-----
From: Robert Collins [mailto:robertc at robertcollins.net] 
Sent: April-04-13 6:23 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Rackspace Plans Contributions to HEAT

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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev