Open Stack

On Jan 30, 2014, at 12:09 PM, Clint Byrum <clint at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev