<font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Mike</font>