Open Stack

Debojyoti Dutta <ddutta at gmail.com> wrote on 10/09/2013 02:48:26 AM:
>
> 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)

I think the cleaner APIs integrate with Nova as well as the three phase 
API you suggested.  Am I missing some obvious impediment?

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

I am talking about how the client/service interface, it is not (just) a 
matter of service implementation.

My complaint is that the software orchestration technique commonly used 
prevents us from having a one-phase API for holistic infrastructure 
scheduling.  The commonly used software orchestration technique requires 
some serialization of the resource creation calls.  For example, if one VM 
instance runs a database and another VM instance runs a web server that 
needs to be configured with the private IP address of the database, the 
common technique is for the client to first create the database VM 
instance, then take the private IP address from that VM instance and use 
it to compose the userdata that is passed in the Nova call that creates 
the web server VM instance.  That client can not present all at once a 
fully concrete and literal specification of both VM instances, because the 
userdata for one is not knowable until the other has been created.  The 
client has to be able to make create-like calls in some particular order 
rather than ask for all creation at once.  If the client could ask for all 
creation at once then we could use a one-phase API: it simply takes a 
specification of the resources along with their policies and 
relationships.

Of course, there is another way out.  We do have in OpenStack a technology 
by which a client can present all at once a specification of many VM 
instances where the userdata of some depend on the results of creating 
others.  If we were willing to use this technology, we could follow A2. 
The CREATE flow would go like this: (i) the client presents the 
specification of resources (including the computations that link some), 
with grouping, relationships, and policies, to our new API; (ii) our new 
service registers the new topology and (once we advance this far on the 
development roadmap) does holistic scheduling; (iii) our new service 
updates the resource specifications to include pointers into the policy 
data; (iv) our new service passes the enhanced resource specifications to 
that other service that can do the creation calls linked by the prescribed 
computations; (v) that other service does its thing, causing a series 
(maybe with some allowed parallelism) of creation calls, each augmented by 
the relevant pointer into the policy information; (vi) the service 
implementing a creation call gets what it normally does plus the policy 
pointer, which it follows to get the relevant policy information (at the 
first step in the development roadmap) or the scheduling decision (in the 
second step of the development roadmap).  But I am getting ahead of myself 
here and discussing backend implementation; I think we are still working 
on the user-facing API.

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

I am not sure I understand that remark.  Of course the API you proposed is 
about enabling the client to express the policy information that we both 
advocate.  I am not sure I understand why you add the qualifier of 
"assuming we will be able to extend the notion of ...".  I do not think we 
(yet) have a policy type catalog set in stone, if that is the concern.  I 
think there is an interesting discussion to have about defining that 
catalog.

BTW, note that the class you called InstanceGroupPolicy is not just a 
reference to a policy, it also specifies one place where that policy is 
being applied.  That is really the class of policy applications (or 
"uses").

I think some types of policies have parameters.  A relationship policy 
about limiting the number of network hops takes a parameter that is the 
hop count limit.  A policy about anti-collocation takes a physical 
hierarchy level as a parameter, to put a lower bound on how different the 
locations are.

Thus, I distinguish between "policy" and "policy type".  An example policy 
type is "anti-collocation"; an example policy is "anti-collocation at the 
rack level".  Note that the concrete syntax I proposed (
https://wiki.openstack.org/wiki/Heat/PolicyExtension) suggests that a 
policy can be handled in the same generic way as resources in Heat: by a 
type name and an arbitrary dictionary of "properties".  This is easy to 
directly reflect in the object model.

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