Open Stack

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.

BR
Alan

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

On 5 April 2013 04:43, Alan Kavanagh <alan.kavanagh at ericsson.com> wrote:
> Adrian
>
>
>
> I can see understand your point but we need to separate the case for 
> Auto-Scaling into two cases as follows: (1) for Network Services that 
> are inherent and part of the Openstack IaaS system (for example LB) 
> and (2) for application that sit on top and can be provisioned through 
> the HEAT API for example (this I can see as a good use of HEAT).

You say that we need to separate it, but you don't say why.

This intruiges me, since the triple-o (openstack [deployed by and] on
openstack) project's entire focus is being able to deploy all of Openstack using Heat. So network services like load balancers will sit within the the bare metal layer cloud and be managed via Heat.

To me that means either a) you know something we don't, and we're doomed to failure, or b) there is no need to separate auto scaling into the (1) and (2) you mention.

Can you help me understand why you say we need to separate auto scaling into two cases?

-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