Open Stack

I have made some edits to the document: https://docs.google.com/document/d/17OIiBoIavih-1y4zzK0oXyI66529f-7JTCVj-BcXURA/edit?pli=1#
by updating the Instance Group Model and APIs based on the recent mailing list discussion below and also about the Policy Model in another email thread.  An action item is to provide some examples of request and response to the REST apis.  But they will be based on enhancements and reuse of some examples already provided here: https://review.openstack.org/#/c/30028/22

This API proposal is still under discussion and work-in-progress,  and will definitely be a good session topic to finalize this proposal.

Regards,
Yathi.


From: Yathiraj Udupi <yudupi at cisco.com<mailto:yudupi at cisco.com>>
Date: Monday, October 14, 2013 10:17 AM
To: Mike Spreitzer <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>>, Debojyoti Dutta <ddutta at gmail.com<mailto:ddutta at gmail.com>>, garyk <gkotton at vmware.com<mailto:gkotton at vmware.com>>
Cc: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [scheduler] APIs for Smart Resource Placement - Updated Instance Group Model and API extension model - WIP Draft

Hi Mike,

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.
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.

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.

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 ?


Now going to the APIs,

Register GROUP API (from my doc [1]):


POST


/v3.0/{tenant_id}/groups


Register a group


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.

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.   (his makes it a 3-phase) 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



POST


/v3.0/{tenant_id}/groups/policy


Register a policy belonging to an instance group



Are we okay with this ?


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.  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

Let me know your thoughts on this.

Thanks,
Yathi.



























-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131015/077aa8ce/attachment.html>