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