Re: [Openstack] [RFC] OpenStack Programming Model Framework

Mon, 03 Jan 2011 18:42:10 -0800


John,
   This is a good approach - I have done some loud API work and this seems reasonable. But there are pitfalls as well:
   a) Need a consistent programming model at the language binding layer. The challenge comes in the richness of the feature set between different VM layers. If this model is a common subset acros different hypervisors, then developers need a way to incorporate the additional features a platform provides (be it compute, storage or network). If it is a superset, then the layer needs to provide for the gap between different virtualization platforms
   b) The programming model needs to be orthogonally extensible so that a new set of API/Service protocol can extend the language bindings (for example a pluggable approach with associated language objects)
   c) BTW, the API/Service protocol need not be always RESTful
   d) It would require a little more coordination and can affect the current nimbleness
   e) Another question to ask is the maturity of the API/Service Protocol layer. One needs a level of stability to design a consistent programming model
Cheers & New Year WIshes
<k/>
-------- Original Message --------
Subject: [Openstack] [RFC] OpenStack Programming Model Framework
From: "John Purrier" <[email protected]>
Date: Mon, January 03, 2011 5:13 pm
To: <[email protected]>

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 | [email protected]
OpenID: http://john.purrier.com | LinkedIn: johnpur
 
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to