<font size=2 face="sans-serif">Thanks for the clue about where the request/response
bodies are documented.  Is there any convenient way to view built
documentation for Havana right now?</font>
<br>
<br><font size=2 face="sans-serif">You speak repeatedly of the desire for
"clean" interfaces, and nobody could disagree with such words.
 I characterize my desire that way too.  It might help me if
you elaborate a little on what "clean" means to you.  To
me it is about minimizing the number of interactions between different
modules/agents and the amount of information in those interactions.  In
short, it is about making narrow interfaces - a form of simplicity.</font>
<br>
<br><font size=2 face="sans-serif">To me the most frustrating aspect of
this challenge is the need for the client to directly mediate the dependencies
between resources; this is really what is driving us to do ugly things.
 As I mentioned before, I am coming from a setting that does not have
this problem.  So I am thinking about two alternatives: (A1) how clean
can we make a system in which the client continues to directly mediate
dependencies between resources, and (A2) how easily and cleanly can we
make that problem go away.</font>
<br>
<br><font size=2 face="sans-serif">For A1, we need the client to make a
distinct activation call for each resource.  You have said that we
should start the roadmap without joint scheduling; in this case, the scheduling
can continue to be done independently for each resource and can be bundled
with the activation call.  That can be the call we know and love today,
the one that creates a resource, except that it needs to be augmented to
also carry some pointer that points into the policy data so that the relevant
policy data can be taken into account when making the scheduling decision.
 Ergo, the client needs to know this pointer value for each resource.
 The simplest approach would be to let that pointer be the combination
of (p1) a VRT's UUID and (p2) the local name for the resource within the
VRT.  Other alternatives are possible, but require more bookkeeping
by the client.</font>
<br>
<br><font size=2 face="sans-serif">I think that at the first step of the
roadmap for A1, the client/service interaction for CREATE can be in just
two phases.  In the first phase the client presents a topology (top-level
InstanceGroup in your terminology), including resource definitions, to
the new API for registration; the response is a UUID for that registered
top-level group.  In the second phase the client "creates"
the resources as is done today, except that each creation call is augmented
to carry the aforementioned pointer into the policy information.  Each
resource scheduler (just nova, at first) can use that pointer to access
the relevant policy information and take it into account when scheduling.
 The client/service interaction for UPDATE would be in the same two
phases: first update the policy&resource definitions at the new API,
then do the individual resource updates in dependency order.</font>
<br>
<br><font size=2 face="sans-serif">I suppose the second step in the roadmap
is to have Nova do joint scheduling.  The client/service interaction
pattern can stay the same.  The only difference is that Nova makes
the scheduling decisions in the first phase rather than the second.  But
that is not a detail exposed to the clients.</font>
<br>
<br><font size=2 face="sans-serif">Maybe the third step is to generalize
beyond nova?</font>
<br>
<br><font size=2 face="sans-serif">For A2, the first question is how to
remove "user-level" create-time dependencies between resources.
 We are only concerned with the "user-level" create-time
dependencies here because it is only they that drive intimate client interactions.
 There are also create-time dependencies due to the nature of the
resource APIs; for example, you can not attach a volume to a VM until after
both have been created.  But handling those kinds of create-time dependencies
does not require intimate interactions with the client.  I know of
two software orchestration technologies developed in IBM, and both have
the property that there are no "user-level" create-time dependencies
between resources; rather, the startup code ("userdata") that
each VM runs handles dependencies (using a library for cross-VM communication
and synchronization).  This can even be done in plain CFN, using wait
conditions and handles (albeit somewhat clunkily), right?  So I think
there are ways to get this nice property already.  The next question
is how best to exploit it to make cleaner APIs.  I think we can have
a one-step client/service interaction: the client presents a top-level
group (including leaf resource definitions) to the new service, which registers
it and proceeds to create/schedule/activate the resources.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Mike</font>