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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
