<tt><font size=2>Stephen Gran <stephen.gran@theguardian.com> wrote
on 09/27/2013 04:26:37 AM:<br>
<br>
> Maybe I'm missing something obvious, but I'm not convinced all that
<br>
> logic belongs in Heat.  I would expect nova and related components
to <br>
> expose grouping information (availability zones in nova, networks
in <br>
> quantum, etc) and for end users to supply the "group by"
information.</font></tt>
<br>
<br><tt><font size=2>Yes, this additional policy information is not intended
to inform infrastructure orchestration.  It is intended to inform
something that I have been calling holistic infrastructure scheduling and
others have called things like unified resource placement and smart resource
placement.  I frame it as an extension to Heat templates because this
policy information needs to be added to a statement about a whole pattern/template/topology
and Heat templates are the language we have for such things.  The
idea is that holistic infrastructure scheduling comes before infrastructure
orchestration; by the time infrastructure orchestration happens, the policy
information has been handled and removed (or, possibly, encapsulated in
some way for downstream processing --- but that's another story I am not
trying to broach yet).</font></tt>
<br>
<br><tt><font size=2>I have been discussing this outline here under the
subject "Bringing things together for Icehouse" (</font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-September/015118.html"><tt><font size=2>http://lists.openstack.org/pipermail/openstack-dev/2013-September/015118.html</font></tt></a><tt><font size=2>),
in the scheduler subgroup and heat weekly IRC meetings, and have a design
summit proposal (</font></tt><a href=http://summit.openstack.org/cfp/details/113><tt><font size=2>http://summit.openstack.org/cfp/details/113</font></tt></a><tt><font size=2>).</font></tt>
<br><tt><font size=2><br>
<br>
> I think that your use case for anti-collocation (which is a very good
<br>
> and important use case, don't get me wrong) is covered by using <br>
> availability zones/cells/regions and so on as they are, and doesn't
<br>
> require much logic internal to Heat beyond obeying the constraint
<br>
> specified by a user.</font></tt>
<br>
<br><tt><font size=2>If there are five racks in the system and I want to
say that two VMs should be placed on different racks, how do I say that
with AZs without being overly specific?</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>