Open Stack

Excerpts from Mike Spreitzer's message of 2013-09-23 20:31:32 -0700:
> 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.
> 

Ok, now I think I understand you.

What you're talking about, in many ways, is very similar to what the
autoscale-interested folk have been proposing. Something that sits
outside of Heat and makes use of other information (alarms/policy/etc)
to tweak a Heat stack.

Only this service would make use of information before a stack was
even created.

I like it, and I do think that it should be "part of heat" because it will
be making use of Heat's templating to make those decisions. However,
I also think it should be a separate repository/project within the
"OpenStack Orchestration" program, to keep it honest with regard to
interfaces. Heat's infrastructure-focused service is already big enough,
we don't need to grow it even more with only slightly-related code.

Also I imagine there are many ways to skin this cat, and thus we may see
alternative holistic schedulers for specific applications (Savannah may
use a hadoop specific approach, as you suggested). There is also the
possibility of chaining schedulers.

The Tuskar project also comes to mind, as the deployment of baremetal with
a mind toward network topology and physical placement (racks/rooms/etc)
for the explicit purpose of deploying OpenStack is itself a form of
holistic scheduling.

> 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?

I do now. I stand by the original position that Heat, as it exists today,
would simply pass along infrastructure scheduling decisions made by a
holistic scheduler. However I think it would be unwise to try and develop
these things apart from one another as it may encourage fracturing the
template language. So I would propose that if there is a more general
purpose attempt at holistic scheduling via Heat templates that it be
done as a separate service/repository within the Heat program.