I favor the second option for the same reasons as Zane described, but also don't think we need a LaunchConfiguration resource. How about just adding a attribute to the resources such that the engine knows is not meant to be handled in the usual way, and instead it is really a "template" (sorry for the overloaded term) used in a scaling group. For example:
group:
type: OS::Heat::ScalingGroup
properties:
scaled_resource: server_for_scaling
server_for_scaling:
use_for_scaling: true ( the name of this attribute is
clearly up for discussion ;-) )
type: OS::Nova::Server
properties:
image: my_image
flavor: m1.large
When the engine sees the "use_for_scaling" set to true, then it does not
call things like "handle_create". Anyway, that's the general idea. I'm sure
there are many other ways to achieve a similar effect.
Edmund Troche
From: Zane Bitter <zbit...@redhat.com>
To: openstack-dev@lists.openstack.org,
Date: 01/30/2014 09:43 AM
Subject: Re: [openstack-dev] [Heat] About LaunchConfiguration and
Autoscaling
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
<<inline: graycol.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
