<tt><font size=2>Chris Friesen <chris.friesen@windriver.com> wrote
on 04/28/2014 10:44:46 AM:<br>
<br>
> On 04/26/2014 09:41 PM, Jay Lau wrote:<br>
> ...<br>
> > My idea is that can we add a new field such as "PlacemenetPolicy"
to<br>
> > AutoScalingGroup? If the value is affinity, then when heat engine
create<br>
> > the AutoScalingGroup, it will first create a server group with
affinity<br>
> > policy, then when create VM instance for the AutoScalingGroup,
heat<br>
> > engine will transfer the server group id as scheduler hints so
as to<br>
> > make sure all the VM instances in the AutoScalingGroup can be
created<br>
> > with affinity policy.<br>
> <br>
> While I personally like this sort of idea from the perspective of
<br>
> simplifying things for heat users, I see two problems.<br>
> <br>
> First, my impression is that heat tries to provide a direct mapping
of <br>
> nova resources to heat resources.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>> Using a property of a heat resource <br>
> to trigger the creation of a nova resource would not fit that model.</font></tt>
<br>
<br><tt><font size=2>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.<br>
<br>
> Second, it seems less well positioned for exposing possible server
group <br>
> enhancements in nova.  For example, one enhancement that has
been <br>
> discussed is to add a server group option to make the group scheduling
<br>
> policy a weighting factor if it can't be satisfied as a filter.  With
<br>
> the server group as an explicit resource there is a natural way to
<br>
> extend it.<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>OTOH, I find nothing particularly bad with doing it
as you suggest.</font></tt>
<br>
<br><tt><font size=2>BTW, this is just the beginning.  What about
resources of type AWS::CloudFormation::Stack?  What about Trove and
Sahara?</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>