<tt><font size=2>Debojyoti Dutta <ddutta@gmail.com> wrote on 10/09/2013
02:48:26 AM:<br>
><br>
> Mike, I agree we could have a cleaner API but I am not sure how<br>
> cleanly it will integrate with current nova which IMO should be test<br>
> we should pass (assuming we do cross services later)</font></tt>
<br>
<br><tt><font size=2>I think the cleaner APIs integrate with Nova as well
as the three phase API you suggested.  Am I missing some obvious impediment?</font></tt>
<br><tt><font size=2><br>
> ...<br>
> > To me the most frustrating aspect of this challenge is the need
for the<br>
> > client to directly mediate the dependencies between resources;
this is<br>
> > really what is driving us to do ugly things.  As I mentioned
before, I am<br>
> > coming from a setting that does not have this problem.  So
I am thinking<br>
> > about two alternatives: (A1) how clean can we make a system in
which the<br>
> > client continues to directly mediate dependencies between resources,
and<br>
> > (A2) how easily and cleanly can we make that problem go away.<br>
> <br>
> Am a little confused - How is the API dictating either A1 or A2? Isnt<br>
> that a function of the implementation of the API.  For a moment
let us<br>
> assume that the black box implementation will be awesome and address<br>
> your concerns.</font></tt>
<br>
<br><tt><font size=2>I am talking about how the client/service interface,
it is not (just) a matter of service implementation.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>> The question is this - does the current API help<br>
> specify what we  want assuming we will be able to extend the
notion of<br>
> nodes, edges, policies and metadata?<br>
</font></tt>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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").</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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 (</font></tt><a href=https://wiki.openstack.org/wiki/Heat/PolicyExtension><tt><font size=2>https://wiki.openstack.org/wiki/Heat/PolicyExtension</font></tt></a><tt><font size=2>)
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.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>