Open Stack

Chris Friesen <chris.friesen at windriver.com> wrote on 04/28/2014 10:44:46 
AM:

> On 04/26/2014 09:41 PM, Jay Lau wrote:
> ...
> > My idea is that can we add a new field such as "PlacemenetPolicy" to
> > AutoScalingGroup? If the value is affinity, then when heat engine 
create
> > the AutoScalingGroup, it will first create a server group with 
affinity
> > policy, then when create VM instance for the AutoScalingGroup, heat
> > engine will transfer the server group id as scheduler hints so as to
> > make sure all the VM instances in the AutoScalingGroup can be created
> > with affinity policy.
> 
> While I personally like this sort of idea from the perspective of 
> simplifying things for heat users, I see two problems.
> 
> First, my impression is that heat tries to provide a direct mapping of 
> nova resources to heat resources.

That matches my understanding too.  But autoscaling groups (all three 
kinds) are already broken in that regard: they are not Nova resources, nor 
resources of any other service, but purely creatures of Heat's creation. 
There is a blueprint for fixing this, but it is only very partially 
implemented at the moment.

> 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?

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/b351a625/attachment.html>