<font size=2 face="sans-serif">I was not trying to raise issues of geographic
dispersion and other higher level structures, I think the issues I am trying
to raise are relevant even without them.  This is not to deny the
importance, or relevance, of higher levels of structure.  But I would
like to first respond to the discussion that I think is relevant even without
them.</font>
<br>
<br><font size=2 face="sans-serif">I think it is valuable for OpenStack
to have a place for holistic infrastructure scheduling.  I am not
the only one to argue for this, but I will give some use cases.  Consider
Hadoop, which stresses the path between Compute and Block Storage.  In
the usual way of deploying and configuring Hadoop, you want each data node
to be using directly attached storage.  You could address this by
scheduling one of those two services first, and then the second with constraints
from the first --- but the decisions made by the first could paint the
second into a corner.  It is better to be able to schedule both jointly.
 Also consider another approach to Hadoop, in which the block storage
is provided by a bank of storage appliances that is equidistant (in networking
terms) from all the Compute.  In this case the Storage and Compute
scheduling decisions have no strong interaction --- but the Compute scheduling
can interact with the network (you do not want to place Compute in a way
that overloads part of the network).</font>
<br>
<br><font size=2 face="sans-serif">Once a holistic infrastructure scheduler
has made its decisions, there is then a need for infrastructure orchestration.
 The infrastructure orchestration function is logically downstream
from holistic scheduling.  I do not favor creating a new and alternate
way of doing infrastructure orchestration in this position.  Rather
I think it makes sense to use essentially today's heat engine.</font>
<br>
<br><font size=2 face="sans-serif">Today Heat is the only thing that takes
a holistic view of patterns/topologies/templates, and there are various
pressures to expand the mission of Heat.  A marquee expansion is to
take on software orchestration.  I think holistic infrastructure scheduling
should be downstream from the preparatory stage of software orchestration
(the other stage of software orchestration is the run-time action in and
supporting the resources themselves).  There are other pressures to
expand the mission of Heat too.  This leads to conflicting usages
for the word "heat": it can mean the infrastructure orchestration
function that is the main job of today's heat engine, or it can mean the
full expanded mission (whatever you think that should be).  I have
been mainly using "heat" in that latter sense, but I do not really
want to argue over naming of bits and assemblies of functionality.  Call
them whatever you want.  I am more interested in getting a useful
arrangement of functionality.  I have updated my picture at </font><a href=https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U><font size=2 face="sans-serif">https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U</font></a><font size=2 face="sans-serif">
--- do you agree that the arrangement of functionality makes sense?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Mike</font>