Open Stack

Clint Byrum <clint at fewbar.com> wrote on 10/17/2013 09:16:12 PM:

> Excerpts from Mike Spreitzer's message of 2013-10-17 17:19:58 -0700:
> > What is the rationale for this new feature?  Since there is already an 

> > autoscaling group implemented by Heat, what is the added benefit here? 
And 
> > why is it being done as another heat-native thing rather than as an 
> > independent service (e.g., as outlined in 
> > https://wiki.openstack.org/wiki/Heat/AutoScaling for an autoscaling 
group 
> > service)?
> 
> This supports that design quite well.
> 
> The point is to be able to group and clone any resource, not just
> server/instance. So autoscaling might be configured to manage a group
> of Trove database instances which are then fed as a list to a group of
> separately autoscaled webservers.

Thanks for the answer.  I'm just a newbie here, trying to understand 
what's going on.  I still don't quite follow.  
https://wiki.openstack.org/wiki/Heat/AutoScaling 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?

BTW, is there some place I could have read the answers to my questions 
about the design thinking here?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131017/7d3559d3/attachment.html>