On Jan 30, 2014, at 12:09 PM, Clint Byrum <cl...@fewbar.com> wrote: > 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.)
This looks a lot like OS::Heat::ResourceGroup, which I believe already addresses some of Zane's concerns around "dynamic" property validation. >> >>> 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. Agreed. Codifying re-use inside specific resource types is a game of catch-up I don't think we can win in the end. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
