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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
