<font size=2 face="sans-serif">That came through beautifully formatted
to me, but it looks much worse in the archive. I'm going to use crude
email tech here, so that I know it won't lose anything in handling.</font>
<br>
<br><tt><font size=2>"Yathiraj Udupi (yudupi)" <yudupi@cisco.com>
wrote on 10/14/2013 01:17:47 PM:<br>
<br>
> I read your email where you expressed concerns regarding create-time<br>
> dependencies, and I agree they are valid concerns to be addressed.
<br>
> But like we all agree, as a starting point, we are just focusing on
<br>
> the APIs for now, and will leave that aside as implementation <br>
> details to be addressed later. </font></tt>
<br>
<br><tt><font size=2>I am not sure I understand your language here. To
me, design decisions that affect what calls the clients make are not implementation
details, they are part of the API design.</font></tt>
<br>
<br><tt><font size=2>> Thanks for sharing your suggestions on how we
can simplify the APIs.<br>
> I think we are getting closer to finalizing this one. </font></tt>
<br><tt><font size=2>> <br>
> Let us start at the model proposed here - </font></tt>
<br><tt><font size=2>> [1] </font></tt><a href=https://docs.google.com/document/d/><tt><font size=2>https://docs.google.com/document/d/</font></tt></a><tt><font size=2><br>
> 17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing </font></tt>
<br><tt><font size=2>> (Ignore the white diamonds - they will be black,
when I edit the doc)</font></tt>
<br><tt><font size=2>> <br>
> The InstanceGroup represents all the information necessary to <br>
> capture the group - nodes, edges, policies, and metadata</font></tt>
<br><tt><font size=2>> <br>
> InstanceGroupMember - is a reference to an Instance, which is saved
<br>
> separately, using the existing Instance Model in Nova.</font></tt>
<br>
<br><tt><font size=2>I think you mean this is a reference to either a group
or an individual Compute instance.</font></tt>
<br>
<br><tt><font size=2>> <br>
> InstanceGroupMemberConnection - represents the edge</font></tt>
<br><tt><font size=2>> <br>
> InstanceGroupPolicy is a reference to a Policy, which will also be
<br>
> saved separately, (currently not existing in the model, but has to
<br>
> be created). Here in the Policy model, I don't mind adding any <br>
> number of additional fields, and key-value pairs to be able to fully<br>
> define a policy. I guess a Policy-metadata dictionary is sufficient<br>
> to capture all the required arguments. </font></tt>
<br><tt><font size=2>> The InstanceGroupPolicy will be associated to
a group as a whole or an edge.</font></tt>
<br>
<br><tt><font size=2>Like I said under separate cover, I think one of these
is a policy *use* rather than a policy *definition*. I go further
and emphasize that the interesting out-of-scope definitions are of policy
*types*. A policy type takes parameters. For example, policies
of the anti-collocation (AKA anti-affinity) type have a parameter that
specifies the level in the physical hierarchy where the location must differ
(rack, host, ...). Each policy type specifies a set of parameters,
just like a procedure specifies parameters; each use of a policy type supplies
values for the parameters, just like a procedure invocation supplies values
for the procedure's parameters. I suggest separating parameter values
from metadata; the former are described by the policy type, while the latter
are unknown to the policy type and are there for other needs of the client.</font></tt>
<br>
<br><tt><font size=2>Yes, a use of a policy type is associated with a group
or an edge. In my own writing I have suggested a third possibility:
that a policy use can be directly associated with an individual resource.
It just so happens that the code my group already has been running
also has your restriction: it supports only policies associated with groups
and relationships. But I suggested allowing direct attachment to
resources (as well as relationships also being able to directly reference
resources instead of groups) because I think this restriction --- while
it simplifies implementation --- makes templates more verbose; I felt the
latter was a more important consideration than the former. If you
want to roadmap this --- restricted first, liberal later --- that's fine
with me.</font></tt>
<br>
<br><tt><font size=2>> <br>
> InstanceGroupMetadata - represents key-value dictionary for any <br>
> additional metadata for the instance group. </font></tt>
<br><tt><font size=2>> <br>
> I think this should fully support what we care about - nodes, edges,<br>
> policies and metadata. </font></tt>
<br><tt><font size=2>> <br>
> Do we all agree ? </font></tt>
<br>
<br><tt><font size=2>Yes, with exceptions noted above.</font></tt>
<br>
<br><tt><font size=2>> <br>
> Now going to the APIs, </font></tt>
<br><tt><font size=2>> <br>
> Register GROUP API (from my doc [1]): </font></tt>
<br><tt><font size=2>> <br>
> POST /v3.0/{tenant_id}/groups --- Register a group</font></tt>
<br>
<br><tt><font size=2>In such specs it would be good to be explicit about
the request parameters and body. If I follow correctly, </font></tt><a href="https://review.openstack.org/#/c/30028/25/doc/api_samples/os-instance-groups/instance-groups-post-req.json"><tt><font size=2>https://review.openstack.org/#/c/30028/25/doc/api_samples/os-instance-groups/instance-groups-post-req.json</font></tt></a><tt><font size=2>
shows us that you intended (as of that patch) the body to carry a group
definition.</font></tt>
<br><tt><font size=2><br>
> I think the confusion is only about when the member (all nested <br>
> members) and policy about when they are saved in the DB (registered,<br>
> but not CREATED actually), such that we can associate a UUID. This
<br>
> led to my original thinking that it is a 3-phase operation where we
<br>
> have to register (save in DB) the nested members first, then <br>
> register the group as a whole. But this is not client friendly.
</font></tt>
<br><tt><font size=2>> <br>
> Like I had suggested earlier, as an implementation detail of the <br>
> Group registration API (CREATE part 1 in your terminology), we can
<br>
> support this: as part of the group registration transaction, <br>
> complete the registration of the nested members, get their UUIDs,
<br>
> create the InstanceGroupMemberConnections, and then complete saving
<br>
> the group - resulting in a UUID for the group, all in a single
<br>
> transaction-scope. While you start the transaction, you can
start <br>
> with a UUID for the group, so that you can add the group_id pointers<br>
> to the individual members, and then finally complete the transaction.
</font></tt>
<br><tt><font size=2>> This means, you provide as an input to
the REST API - the complete <br>
> nested tree, including all the details about the nested members and
<br>
> policies, and the register API, will handle the saving of all the
<br>
> individual objects required.</font></tt>
<br>
<br><tt><font size=2>Yes, I think the body should carry a top-level group
and everything contained in it --- although we have open issues about how
much is said about the leaf resources.</font></tt>
<br><tt><font size=2><br>
> But I think it does help to also add additional APIs to just <br>
> register an InstanceGroupMember and an InstanceGroupPolicy <br>
> separately. This might help the client while creating a group,
<br>
> rather than giving the entire nested tree. ([T]his makes it
a 3-<br>
> phase)</font></tt>
<br>
<br><tt><font size=2>This surprises me. Why would someone want that
if the 2-phase API is also available?</font></tt>
<br>
<br><tt><font size=2>> This API will support adding members and policies
to an <br>
> instance group that is created. (you can start with an empty
group)</font></tt>
<br><tt><font size=2>> <br>
> POST /v3.0/{tenant_id}/groups/instance --- Register an instance belonging
to an instancegroup</font></tt>
<br>
<br><tt><font size=2>I could use some explicit details about parameters
and body here. Presumably a request parameter carries the UUID of
a group that has already been created. Has the instance already been
created/registered in any sense before this call? By what sort of
ID is it known in input/output of this call? How much information
is supplied in this call about the instance?</font></tt>
<br><tt><font size=2><br>
> POST /v3.0/{tenant_id}/groups/policy --- Register a policy belonging
to an instance group</font></tt>
<br>
<br><tt><font size=2>I presume that the request parameters identify a pre-existing
group and the request body carries a policy use.</font></tt>
<br>
<br><tt><font size=2>In this 3-phase approach, what about nested groups?</font></tt>
<br><tt><font size=2><br>
> Are we okay with this ? </font></tt>
<br>
<br><tt><font size=2>Not sure, hope to learn more about it.</font></tt>
<br>
<br><tt><font size=2>Since I want to get to joint decision-making, this
approach would also need a way to demarcate when the group construction
is complete and the decision-making can commence.</font></tt>
<br><tt><font size=2><br>
> The next API - is the actual creation of the resources. (CREATE
<br>
> part 2 in your terminology). This is was my create API
in the doc- </font></tt>
<br><tt><font size=2>> <br>
> POST /v3.0/{tenant_id}/groups/{id}/create --- Create and schedule
an Instance group </font></tt>
<br><tt><font size=2>> <br>
> This is just the API proposal, the underlying implementation details<br>
> will involve all the required logic to ensure the creation of all
<br>
> the group members.</font></tt>
<br>
<br><tt><font size=2>Again, being explicit about request parameters and
body would help me here.</font></tt>
<br>
<br><tt><font size=2>If this call takes the whole group definition as input
and goes as far as activating the instances then it is a one-phase API.
That is what I would prefer to see, but in order to get there we
have to do something about the fact that infrastructure orchestration is
downstream from joint scheduling. I do not mean change that fact;
it is unavoidable. I mean agree on how to deal with it. I see
two approaches: (1) require the client to use a software orchestration
technique that imposes (for its own sake) no ordering constraints between
resources or (2) accept ordering constraints in the group input and use
(downstream from this API) the existing OpenStack service that can orchestrate
against an arbitrary DAG of given ordering constraints.</font></tt>
<br>
<br><tt><font size=2>> Here like you also suggest, as a starting point,<br>
> we can try to first use existing Nova mechanisms to create the <br>
> members of this group. Eventually we will need to get to the
<br>
> discussions for scheduling this entire group as a whole, which <br>
> covers cross-services support like I discuss in the unified resource<br>
> placement document - </font></tt><a href=https://docs.google.com/document/d/><tt><font size=2>https://docs.google.com/document/d/</font></tt></a><tt><font size=2><br>
> 1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1 </font></tt>
<br>
<br><tt><font size=2>Yes, I want to get there too.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>