Open Stack

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.

"Yathiraj Udupi (yudupi)" <yudupi at cisco.com> wrote on 10/14/2013 01:17:47 
PM:

> I read your email where you expressed concerns regarding create-time
> dependencies, and I agree they are valid concerns to be addressed. 
> But like we all agree, as a starting point, we are just focusing on 
> the APIs for now, and will leave that aside as implementation 
> details to be addressed later. 

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.

> Thanks for sharing your suggestions on how we can simplify the APIs.
> I think we are getting closer to finalizing this one. 
> 
> Let us start at the model proposed here - 
> [1] https://docs.google.com/document/d/
> 17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?usp=sharing 
> (Ignore the white diamonds - they will be black, when I edit the doc)
> 
> The InstanceGroup represents all the information necessary to 
> capture the group - nodes, edges, policies, and metadata
> 
> InstanceGroupMember - is a reference to an Instance, which is saved 
> separately, using the existing Instance Model in Nova.

I think you mean this is a reference to either a group or an individual 
Compute instance.

> 
> InstanceGroupMemberConnection - represents the edge
> 
> InstanceGroupPolicy is a reference to a Policy, which will also be 
> saved separately, (currently not existing in the model, but has to 
> be created). Here in the Policy model, I don't mind adding any 
> number of additional fields, and key-value pairs to be able to fully
> define a policy.  I guess a Policy-metadata dictionary is sufficient
> to capture all the required arguments. 
> The InstanceGroupPolicy will be associated to a group as a whole or an 
edge.

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.

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.

> 
> InstanceGroupMetadata - represents key-value dictionary for any 
> additional metadata for the instance group. 
> 
> I think this should fully support what we care about - nodes, edges,
> policies and metadata. 
> 
> Do we all agree ? 

Yes, with exceptions noted above.

> 
> Now going to the APIs, 
> 
> Register GROUP API (from my doc [1]): 
> 
> POST  /v3.0/{tenant_id}/groups --- Register a group

In such specs it would be good to be explicit about the request parameters 
and body.  If I follow correctly, 
https://review.openstack.org/#/c/30028/25/doc/api_samples/os-instance-groups/instance-groups-post-req.json 
shows us that you intended (as of that patch) the body to carry a group 
definition.

> I think the confusion is only about when the member (all nested 
> members) and policy about when they are saved in the DB (registered,
> but not CREATED actually), such that we can associate a UUID.  This 
> led to my original thinking that it is a 3-phase operation where we 
> have to register (save in DB) the nested members first, then 
> register the group as a whole.  But this is not client friendly. 
> 
> Like I had suggested earlier, as an implementation detail of the 
> Group registration API (CREATE part 1 in your terminology), we can 
> support this: as part of the group registration transaction, 
> complete the registration of the nested members, get their UUIDs, 
> create the InstanceGroupMemberConnections, and then complete saving 
> the group - resulting in a UUID for the group,  all in a single 
> transaction-scope.  While you start the transaction, you can start 
> with a UUID for the group, so that you can add the group_id pointers
> to the individual members,  and then finally complete the transaction. 
> This means,  you provide as an input to the REST API - the complete 
> nested tree, including all the details about the nested members and 
> policies, and the register API, will handle the saving of all the 
> individual objects required.

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.

> But I think it does help to also add additional APIs to just 
> register an InstanceGroupMember and  an InstanceGroupPolicy 
> separately.  This might help the client while creating a group, 
> rather than giving the entire nested tree.   ([T]his makes it a 3-
> phase)

This surprises me.  Why would someone want that if the 2-phase API is also 
available?

> This API will support adding members and policies to an 
> instance group that is created.  (you can start with an empty group)
> 
> POST /v3.0/{tenant_id}/groups/instance --- Register an instance 
belonging to an instancegroup

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?

> POST /v3.0/{tenant_id}/groups/policy --- Register a policy belonging to 
an instance group

I presume that the request parameters identify a pre-existing group and 
the request body carries a policy use.

In this 3-phase approach, what about nested groups?

> Are we okay with this ? 

Not sure, hope to learn more about it.

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.

> The next API - is the actual creation of the resources.  (CREATE 
> part 2  in your terminology).   This is was my create API in the doc- 
> 
> POST /v3.0/{tenant_id}/groups/{id}/create --- Create and schedule an 
Instance group 
> 
> This is just the API proposal, the underlying implementation details
> will involve all the required logic to ensure the creation of all 
> the group members.

Again, being explicit about request parameters and body would help me 
here.

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.

> Here like you also suggest, as a starting point,
> we can try to first use existing Nova mechanisms to create the 
> members of this group.  Eventually we will need to get to the 
> discussions for scheduling this entire group as a whole, which 
> covers cross-services support like I discuss in the unified resource
> placement document - https://docs.google.com/document/d/
> 1IiPI0sfaWb1bdYiMWzAAx0HYR6UqzOan_Utgml5W1HI/edit?pli=1 

Yes, I want to get there too.

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