<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, 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";}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>OpenStack Programming Model Framework [Request for Comments]<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is a view of the stack, from service up to happy users and administrators:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><img width=487 height=510 id="Picture_x0020_4" src="cid:image001.jpg@01CBAB71.EE9DE350"><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Terms:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><u>Service</u>: A logical set of functions that present a set of API’s.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><u>OpenStack Application Developers: </u>The target audience for the OpenStack Programming Model.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><u>OpenStack User Experience: </u>Applications and Control panels that are built on the programming model.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Comments?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-John<u><o:p></o:p></u></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:gray'>John Purrier</span><span style='color:gray'><o:p></o:p></span></p><p class=MsoNormal><span style='color:gray'>(206) 930-0788 | </span><span style='color:#61B7D5'><a href="mailto:john@openstack.org"><span style='color:#61B7D5'>john@openstack.org</span></a></span><span style='color:gray'><o:p></o:p></span></p><p class=MsoNormal><span style='color:gray'>OpenID: http://</span><span style='color:#61B7D5'><a href="http://john.purrier.com/"><span style='color:#61B7D5'>john.purrier.com</span></a></span><span style='color:#365F91'> </span><span style='color:gray'>|</span><span style='color:#365F91'> </span><span style='color:gray'>LinkedIn:</span><span style='color:#548DD4'> </span><span style='color:#61B7D5'><a href="http://www.linkedin.com/in/johnpur"><span style='color:#61B7D5'>johnpur</span></a></span><span style='color:gray'><o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>