<tt><font size=2>Clint Byrum <clint@fewbar.com> wrote on 10/17/2013
09:16:12 PM:<br>
<br>
> Excerpts from Mike Spreitzer's message of 2013-10-17 17:19:58 -0700:<br>
> > What is the rationale for this new feature?  Since there
is already an <br>
> > autoscaling group implemented by Heat, what is the added benefit
here? And <br>
> > why is it being done as another heat-native thing rather than
as an <br>
> > independent service (e.g., as outlined in <br>
> > </font></tt><a href=https://wiki.openstack.org/wiki/Heat/AutoScaling><tt><font size=2>https://wiki.openstack.org/wiki/Heat/AutoScaling</font></tt></a><tt><font size=2>
for an autoscaling group <br>
> > service)?<br>
> <br>
> This supports that design quite well.<br>
> <br>
> The point is to be able to group and clone any resource, not just<br>
> server/instance. So autoscaling might be configured to manage a group<br>
> of Trove database instances which are then fed as a list to a group
of<br>
> separately autoscaled webservers.<br>
</font></tt>
<br><tt><font size=2>Thanks for the answer.  I'm just a newbie here,
trying to understand what's going on.  I still don't quite follow.
 </font></tt><a href=https://wiki.openstack.org/wiki/Heat/AutoScaling><tt><font size=2>https://wiki.openstack.org/wiki/Heat/AutoScaling</font></tt></a><tt><font size=2>
says that what's autoscaled is a set of resources, not just one.  Can
there be dependencies among the resources in that set?  For example,
is the intent that I could autoscale a pair of (DB server, web server)
where the web server's properties depend on the DB server's attributes?
 If so, would it be problematic to implement that in terms of a pair
of Heat-native resource groups?</font></tt>
<br>
<br><tt><font size=2>BTW, is there some place I could have read the answers
to my questions about the design thinking here?</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>