Clint Byrum <[email protected]> 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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
