Open Stack

Mike, I agree we could have a cleaner API but I am not sure how
cleanly it will integrate with current nova which IMO should be test
we should pass (assuming we do cross services later)

On Tue, Oct 8, 2013 at 10:39 PM, Mike Spreitzer <mspreitz at us.ibm.com> wrote:
> 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?
>
> 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.
>

I think the word clean can be overloaded. For me a clean API is to use
minimal nouns and specify the policies, the resources we would like to
request and the extra metadata that we might want to pass. Thus the
three components.

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

Am a little confused - How is the API dictating either A1 or A2? Isnt
that a function of the implementation of the API. For a moment let us
assume that the black box implementation will be awesome and address
your concerns. The question is this - does the current API help
specify what we  want assuming we will be able to extend the notion of
nodes, edges, policies and metadata?

debo

>
> 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.
>
> 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.
>
> 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.
>
> Maybe the third step is to generalize beyond nova?
>
> 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.
>
> Regards,
> Mike
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
-Debo~