Open Stack

Someone earlier asked for greater clarity about infrastructure 
orchestration, so here is my view.  I see two main issues: (1) deciding 
the order in which to do things, and (2) doing them in an acceptable 
order.  That's an oversimplified wording because, in general, some 
parallelism is possible.  In general, the set of things to do is 
constrained by a partial order --- and that partial order comes from two 
sources.  One is the nature of the downstream APIs.  For examples, you can 
not attach a volume or floating IP address to a VM until after both have 
been created.  The other source of ordering constraints is upstream 
decision makers.  Decisions made upstream are conveyed into today's heat 
engine by data dependencies between resources in a heat template.  The 
heat engine is not making those decisions.  It is not a source of 
important ordering constraints.  When the ordering constraints actually 
allow some parallelism --- they do not specify a total order --- the heat 
engine has freedom in which of that parallelism to exploit vs flatten into 
sequential ordering.  What today's heat engine does is make its available 
choices about that and issue the operations, keeping track of IDs and 
outcomes.  I have been using the term "infrastructure orchestration" to 
refer to this latter job (issuing infrastructure operations with 
acceptable ordering/parallelism), not the decision-making of upstream 
agents.  This might be confusing; I think the plain English meaning of 
"orchestration" suggests decision-making as well as execution.

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