Open Stack

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 <zbitter at redhat.com>
To:	openstack-dev at 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/7598e033/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/7598e033/attachment.gif>