<font size=2 face="sans-serif">Good summary. I would also add that in
A1 the schedulers (e.g., in Nova and Cinder) could talk to each other to
coordinate. Besides defining the policy, and the user-facing APIs, I think
we should also outline those cross-component APIs (need to think whether
they have to be user-visible, or can be admin).</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Mike Spreitzer <mspreitz@us.ibm.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Yathiraj Udupi
(yudupi)" <yudupi@cisco.com>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">OpenStack Development
Mailing List <openstack-dev@lists.openstack.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/10/2013 08:46 AM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[scheduler] APIs for Smart Resource Placement - Updated Instance Group
Model and API extension model - WIP Draft</font>
<br>
<hr noshade>
<br>
<br>
<br><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><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
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><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
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><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
Maybe the third step is to generalize beyond nova?</font><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
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><font size=3>
<br>
</font><font size=2 face="sans-serif"><br>
Regards,</font><font size=3> </font><font size=2 face="sans-serif"><br>
Mike</font><tt><font size=2>_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br>