Open Stack

On 30/01/14 06:01, Thomas Herve wrote:
> Hi all,
>
> While talking to Zane yesterday, he raised an interesting question about whether or not we want to keep a LaunchConfiguration object for the native autoscaling resources.
>
> The LaunchConfiguration object basically holds properties to be able to fire new servers in a scaling group. In the new design, we will be able to start arbitrary resources, so we can't keep a strict LaunchConfiguration object as it exists, as we can have arbitrary properties.
>
> It may be still be interesting to store it separately to be able to reuse it between groups.
>
> So either we do this:
>
> group:
>    type: OS::Heat::ScalingGroup
>    properties:
>      scaled_resource: OS::Nova::Server
>      resource_properties:
>        image: my_image
>        flavor: m1.large

The main advantages of this that I see are:

* It's one less resource.
* We can verify properties against the scaled_resource at the place the 
LaunchConfig is defined. (Note: in _both_ models these would be verified 
at the same place the _ScalingGroup_ is defined.)

> Or:
>
> group:
>    type: OS::Heat::ScalingGroup
>    properties:
>      scaled_resource: OS::Nova::Server
>      launch_configuration: server_config
> server_config:
>    type: OS::Heat::LaunchConfiguration
>    properties:
>      image: my_image
>      flavor: m1.large


I favour this one for a few reasons:

* A single LaunchConfiguration can be re-used by multiple scaling 
groups. Reuse is good, and is one of the things we have been driving 
toward with e.g. software deployments.
* Assuming the Autoscaling API and Resources use the same model (as they 
should), in this model the Launch Configuration can be defined in a 
separate template to the scaling group, if the user so chooses. Or it 
can even be defined outside Heat and passed in as a parameter.
* We can do the same with the LaunchConfiguration for the existing 
AWS-compatibility resources. That will allows us to fix the current 
broken implementation that goes magically fishing in the local stack for 
launch configs[1]. If we pick a model that is strictly less powerful 
than stuff we already know we have to support, we will likely be stuck 
with broken hacks forever :(

> (Not sure we can actually define dynamic properties, in which case it'd be behind a top property.)

(This part is just a question of how the resource would look in Heat, 
and the answer would not really effect the API.)

I think this would be possible, but it would require working around the 
usual code we have for managing/validating properties. Probably not a 
show-stopper, but it is more work. If we can do this there are a couple 
more benefits to this way:

* Extremely deeply nested structures are unwieldy to deal with, both for 
us as developers[2] and for users writing templates; shallower 
hierarchies are better.
* You would be able to change an OS::Nova::Server resource into a 
LaunchConfiguration, in most cases, just by changing the resource type. 
(This also opens up the possibility of switching between them using the 
environment, although I don't know how useful that would be.)

cheers,
Zane.

[1] https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism
[2] 
https://github.com/openstack/heat/blob/master/contrib/rackspace/heat/engine/plugins/auto_scale.py