<tt><font size=2>Stephen Gran <stephen.gran@theguardian.com> wrote
on 09/27/2013 10:46:09 AM:<br>
<br>
> If the admins of the openstack install wanted users to be able to
select <br>
> placement by rack, surely the availability zones would be rack1 -
rack5 <br>
> ?  In this case, the user would write:<br>
> <br>
>    "Resources" : {<br>
>      "MyASG" : {<br>
>        "Type" : "AWS::AutoScaling::AutoScalingGroup",<br>
>        "Properties" : {<br>
>          "AvailabilityZones" :
{ "Fn::GetAZs" : ""},<br>
>          "MinSize" : "2",<br>
>    "DesiredSize": "2",<br>
>          "MaxSize" : "2",<br>
>        }<br>
>      },</font></tt>
<br><tt><font size=2>> <br>
> This should naturally implement placement as spread evenly across
AZs.<br>
</font></tt>
<br><tt><font size=2>You have added that "DesiredSize" property,
to convey the idea of spreading across at least some number (2 in this
case) of AZs, right?  That is, it is not functionality in today's
Nova, rather something we could add.</font></tt>
<br>
<br><tt><font size=2>What if the cloud in question has several levels of
structure available, and the admins want users to be able to spread at
any of the available levels?</font></tt>
<br><tt><font size=2><br>
> I think maybe this is where I think my disagreement is.  Heat
should be <br>
> able to express a user preference for placement, but only within the
<br>
> bounds of the policy already created by the admins of the nova install.
<br>
>   To have Heat have more knowledge than what is available via
the nova <br>
> API seems overcomplicated and fragile to me.  If the nova API
should <br>
> grow some extensions to make more complicated placement algorithms
<br>
> available, then that's an argument that might have legs.<br>
</font></tt>
<br><tt><font size=2>I am trying to find a way to introduce holistic infrastructure
scheduling, whose purpose in life is to do what Nova, Cinder, etc can not
do on their own.  (Making Nova, Cinder, and friends more capable on
their own is also good, and complements what I am advocating.)  Yes,
this requires some more visibility and control from those individual services.
 Those needs have come up in vague ways in the discussion so far,
and I plan to write something specific.</font></tt>
<br>
<br><tt><font size=2>I am distinctly NOT advocating mixing holistic infrastructure
scheduling up with infrastructure orchestration.  I think holistic
infrastructure scheduling happens prior to infrastructure orchestration.
 The more debatable question is the ordering with respect to the preparatory
stage of software orchestration.  Another complicating factor is what
happens when the infrastructure orchestration calls out to something that
makes a nested stack.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>