Open Stack

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.

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).

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.

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 
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U 
--- do you agree that the arrangement of functionality makes sense?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130923/3363d446/attachment.html>