<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div><br>John,</div><div> This is a good approach - I have done some loud API work and this seems reasonable. But there are pitfalls as well:</div><div> 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</div><div> 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)</div><div> c) BTW, the API/Service protocol need not be always RESTful</div><div> d) It would require a little more coordination and can affect the current nimbleness</div><div> 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</div><div>Cheers & New Year WIshes</div><div><k/><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size: 10pt; color: black; font-family: verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: [Openstack] [RFC] OpenStack Programming Model Framework<br>
From: "John Purrier" <<a href="mailto:john@openstack.org">john@openstack.org</a>><br>
Date: Mon, January 03, 2011 5:13 pm<br>
To: <<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
<br>
<!--[if !mso]><style>
#wmQuoteWrapper v\:* {behavior:url(#default#VML);}
#wmQuoteWrapper o\:* {behavior:url(#default#VML);}
#wmQuoteWrapper w\:* {behavior:url(#default#VML);}
#wmQuoteWrapper .shape {behavior:url(#default#VML);}
</style><![endif]--><style>
#wmQuoteWrapper /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}
#wmQuoteWrapper @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;}
#wmQuoteWrapper @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;}
#wmQuoteWrapper /* Style Definitions */ p.MsoNormal, #wmQuoteWrapper li.MsoNormal, #wmQuoteWrapper div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:11.0pt; font-family:"Calibri","sans-serif";}
#wmQuoteWrapper a:link, #wmQuoteWrapper span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}
#wmQuoteWrapper a:visited, #wmQuoteWrapper span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;}
#wmQuoteWrapper p.MsoAcetate, #wmQuoteWrapper li.MsoAcetate, #wmQuoteWrapper div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";}
#wmQuoteWrapper span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;}
#wmQuoteWrapper span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";}
#wmQuoteWrapper .MsoChpDefault {mso-style-type:export-only;}
#wmQuoteWrapper @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;}
#wmQuoteWrapper div.WordSection1 {page:WordSection1;}
</style><div class="WordSection1"><div class="MsoNormal" style="font-size:12pt;">OpenStack Programming Model Framework [Request for Comments]<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">Here is a view of the stack, from service up to happy users and administrators:<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;"><img id="Picture_x0020_4" src="cid:image001.jpg@01CBAB71.EE9DE350" wbeuser="ksankar@doubleclix.net" height="510" width="487"><o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">Terms:<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>Service</u>: A logical set of functions that present a set of API’s.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>API/Service Protocol</u>: 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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>OpenStack Programming Model: </u>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. <o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>OpenStack Application Developers: </u>The target audience for the OpenStack Programming Model.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>OpenStack User Experience: </u>Applications and Control panels that are built on the programming model.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><u>OpenStack Users & Administrators: </u>The actual end users of all the work being done to build OpenStack and the associated ecology around the project.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;margin-left: 0.5in;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">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.<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">Comments?<o:p></o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;">-John<u><o:p></o:p></u></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div><div class="MsoNormal" style="font-size:12pt;"><span style="color: gray;">John Purrier</span><span style="color: gray;"><o:p></o:p></span></div><div class="MsoNormal" style="font-size:12pt;"><span style="color: gray;">(206) 930-0788 | </span><span style="color: rgb(97, 183, 213);"><a target="_blank" href="mailto:john@openstack.org"><span style="color: rgb(97, 183, 213);">john@openstack.org</span></a></span><span style="color: gray;"><o:p></o:p></span></div><div class="MsoNormal" style="font-size:12pt;"><span style="color: gray;">OpenID: http://</span><span style="color: rgb(97, 183, 213);"><a target="_blank" href="http://john.purrier.com/"><span style="color: rgb(97, 183, 213);">john.purrier.com</span></a></span><span style="color: rgb(54, 95, 145);"> </span><span style="color: gray;">|</span><span style="color: rgb(54, 95, 145);"> </span><span style="color: gray;">LinkedIn:</span><span style="color: rgb(84, 141, 212);"> </span><span style="color: rgb(97, 183, 213);"><a target="_blank" href="http://www.linkedin.com/in/johnpur"><span style="color: rgb(97, 183, 213);">johnpur</span></a></span><span style="color: gray;"><o:p></o:p></span></div><div class="MsoNormal" style="font-size:12pt;"><o:p> </o:p></div></div><hr>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>
</div>
</blockquote></span></body></html>