openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

OpenStack Programming Model Framework [Request for Comments]

 

We have had some good discussion about what the OpenStack Compute API should
be and the state of the code for Bexar and Cactus. A lot of work is being
done to get the core Nova functionality exposed through the OpenStack API
along with a set of command line tools.

 

I would like to raise the question of how OpenStack (Nova in particular)
presents a consistent and unified programming model to application
developers. In addition, the programming model framework can be the logical
point to introduce provisioning orchestration, deployment specific rules,
and higher level verbs than are available via the service API's.

 

Note that this proposal does not describe the actual programming model that
will be exposed to developers, but just a framework. We will need to have a
focused effort to define the actual model, produce developer documentation
for each language, and hopefully get it all done by Cactus.

 

Here is a view of the stack, from service up to happy users and
administrators:

 



 

Terms:

 

Service: A logical set of functions that present a set of API's.

 

API/Service Protocol: RESTful interfaces specific to each service. Each
service will present a Public API, a Management API, and optionally, a
Notification API. The set and format of the service interface calls define
the Service Protocol.

 

OpenStack Programming Model: The set of functions and calls that OpenStack
Application Developers will interact with. These will be presented through
various language bindings, the only restriction is that consistency between
implementations in maintained. 

 

OpenStack Application Developers: The target audience for the OpenStack
Programming Model.

 

OpenStack User Experience: Applications and Control panels that are built on
the programming model.

 

OpenStack Users & Administrators: The actual end users of all the work being
done to build OpenStack and the associated ecology around the project.

 

The key concept being proposed is that the developers that will be
interacting with the OpenStack services will not interact directly with the
service API's, but rather will have a set of published language bindings
that define the programming model. This does not preclude direct service
calls, but this will be discouraged in favor of using the bindings. The
bindings will be considered the "Nova API" for all intents and purposes.

 

By introducing this level of abstraction we have the ability to provide
levels of orchestration that will make developing against the platform
easier and quicker. While we may choose to expose direct service API
mappings, it is likely that a set of heuristics and rules will be developed
that ease the developer's burden in building applications for the cloud.
These can be bundled into single calls, are tested to be compatible, and
remove the lower level orchestration burden from the application developer.

 

It will be necessary to first define each of the service API's and
protocols. Then a consistent developer focused model can be developed that
can be exposed through several different languages. Once we have general
agreement on the approach we can start to figure out who needs to do what to
make this real. This is a doc effort as well, as the tenor of the developers
documentation needs to be oriented to this approach.

 

Comments?

 

-John

 

 

John Purrier

(206) 930-0788 |  <mailto:john@xxxxxxxxxxxxx> john@xxxxxxxxxxxxx

OpenID: http:// <http://john.purrier.com/> john.purrier.com | LinkedIn:
<http://www.linkedin.com/in/johnpur> johnpur