<html><body>
<p><font size="2" face="sans-serif">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:</font><br>
<br>
<tt><font size="2">group:<br>
type: OS::Heat::ScalingGroup<br>
properties:<br>
scaled_resource: server_for_scaling<br>
</font></tt><br>
<tt><font size="2">server_for_scaling:</font></tt><br>
<tt><font size="2"> use_for_scaling: true ( the name of this attribute is clearly up for discussion ;-) )<br>
type: OS::Nova::Server<br>
properties:<br>
image: my_image<br>
flavor: m1.large<br>
</font></tt><br>
<font size="2" face="sans-serif">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.</font><br>
<font size="2" face="sans-serif"><br>
</font><br>
<font size="2" face="sans-serif">Edmund Troche</font><br>
<br>
<img width="16" height="16" src="cid:1__=09BBF6E3DFCFAF0A8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Zane Bitter ---01/30/2014 09:43:48 AM---On 30/01/14 06:01, Thomas Herve wrote: > Hi all,"><font size="2" color="#424282" face="sans-serif">Zane Bitter ---01/30/2014 09:43:48 AM---On 30/01/14 06:01, Thomas Herve wrote: > Hi all,</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Zane Bitter <zbitter@redhat.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">openstack-dev@lists.openstack.org, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">01/30/2014 09:43 AM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [Heat] About LaunchConfiguration and Autoscaling</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">On 30/01/14 06:01, Thomas Herve wrote:<br>
> Hi all,<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> It may be still be interesting to store it separately to be able to reuse it between groups.<br>
><br>
> So either we do this:<br>
><br>
> group:<br>
> type: OS::Heat::ScalingGroup<br>
> properties:<br>
> scaled_resource: OS::Nova::Server<br>
> resource_properties:<br>
> image: my_image<br>
> flavor: m1.large<br>
<br>
The main advantages of this that I see are:<br>
<br>
* It's one less resource.<br>
* We can verify properties against the scaled_resource at the place the <br>
LaunchConfig is defined. (Note: in _both_ models these would be verified <br>
at the same place the _ScalingGroup_ is defined.)<br>
<br>
> Or:<br>
><br>
> group:<br>
> type: OS::Heat::ScalingGroup<br>
> properties:<br>
> scaled_resource: OS::Nova::Server<br>
> launch_configuration: server_config<br>
> server_config:<br>
> type: OS::Heat::LaunchConfiguration<br>
> properties:<br>
> image: my_image<br>
> flavor: m1.large<br>
<br>
<br>
I favour this one for a few reasons:<br>
<br>
* A single LaunchConfiguration can be re-used by multiple scaling <br>
groups. Reuse is good, and is one of the things we have been driving <br>
toward with e.g. software deployments.<br>
* Assuming the Autoscaling API and Resources use the same model (as they <br>
should), in this model the Launch Configuration can be defined in a <br>
separate template to the scaling group, if the user so chooses. Or it <br>
can even be defined outside Heat and passed in as a parameter.<br>
* We can do the same with the LaunchConfiguration for the existing <br>
AWS-compatibility resources. That will allows us to fix the current <br>
broken implementation that goes magically fishing in the local stack for <br>
launch configs[1]. If we pick a model that is strictly less powerful <br>
than stuff we already know we have to support, we will likely be stuck <br>
with broken hacks forever :(<br>
<br>
> (Not sure we can actually define dynamic properties, in which case it'd be behind a top property.)<br>
<br>
(This part is just a question of how the resource would look in Heat, <br>
and the answer would not really effect the API.)<br>
<br>
I think this would be possible, but it would require working around the <br>
usual code we have for managing/validating properties. Probably not a <br>
show-stopper, but it is more work. If we can do this there are a couple <br>
more benefits to this way:<br>
<br>
* Extremely deeply nested structures are unwieldy to deal with, both for <br>
us as developers[2] and for users writing templates; shallower <br>
hierarchies are better.<br>
* You would be able to change an OS::Nova::Server resource into a <br>
LaunchConfiguration, in most cases, just by changing the resource type. <br>
(This also opens up the possibility of switching between them using the <br>
environment, although I don't know how useful that would be.)<br>
<br>
cheers,<br>
Zane.<br>
<br>
[1] </font></tt><tt><font size="2"><a href="https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism">https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism</a></font></tt><tt><font size="2"><br>
[2] <br>
</font></tt><tt><font size="2"><a href="https://github.com/openstack/heat/blob/master/contrib/rackspace/heat/engine/plugins/auto_scale.py">https://github.com/openstack/heat/blob/master/contrib/rackspace/heat/engine/plugins/auto_scale.py</a></font></tt><tt><font size="2"><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>