Open Stack

On 04/30/2014 03:41 PM, Mike Spreitzer wrote:
> Chris Friesen <chris.friesen at windriver.com> wrote on 04/28/2014 10:44:46 AM:

>  > Using a property of a heat resource
>  > to trigger the creation of a nova resource would not fit that model.
>
> For the sake of your argument, let's pretend that the new ASG blueprint
> has been fully implemented.  That means an ASG is an ordinary virtual
> resource.  In all likelihood the implementation will generate templates
> and make nested stacks.  I think it is fairly natural to suppose that
> the generated template could include a Nova server group.
>
>  > Second, it seems less well positioned for exposing possible server group
>  > enhancements in nova.  For example, one enhancement that has been
>  > discussed is to add a server group option to make the group scheduling
>  > policy a weighting factor if it can't be satisfied as a filter.  With
>  > the server group as an explicit resource there is a natural way to
>  > extend it.
>
> Abstractly an autoscaling group is a sub-class of "group of servers"
> (ignoring the generalization of "server" in the relevant cases), so it
> would seem natural to me that the properties of an autoscaling group
> would include the properties of a server group.  As the latter evolves,
> so would the former.
>
> OTOH, I find nothing particularly bad with doing it as you suggest.
>
> BTW, this is just the beginning.  What about resources of type
> AWS::CloudFormation::Stack?  What about Trove and Sahara?


If we go with what Zane suggested (using the already-exposed 
scheduler_hints) then by implementing a single "server group" resource 
we basically get support for server groups "for free" in any resource 
that exposes scheduler hints.

That seems to me to be an excellent reason to go that route rather than 
modifying all the different group-like resources that heat supports.

Chris