Open Stack

Excerpts from Zane Bitter's message of 2014-01-30 07:38:38 -0800:
> 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.

I agree with the desire for re-use. In fact I am somewhat desperate to
have it as we try to write templates which allow assembling different
topologies of OpenStack deployment.

I would hope we would solve that at a deeper level, rather than making
resources for the things we think will need re-use. I think nested stacks
allow this level of re-use already anyway. Software config just allows
sub-resource composition.