<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)"><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:12.0pt;
font-family:"Times New Roman","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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:black;}
.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="1026" />
</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><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Hi Chris, I think you answered your concern in your posting… OpenStack Compute needs to have an open API that is community driven. This obviously cannot be the Amazon EC2 API, as it is not open. The Rackspace Cloud Servers API was designated to be the basis for the OpenStack Compute API as it is published under an open source license, covered most of the virtual machine provisioning and management functionality, and is syntactically and architecturally close to the desired format for the OpenStack project.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>There is nothing stated or implied that competing APIs should be hindered or development slowed down. What is stated is that serious progress needs to be made to have the OpenStack Compute API functional in Bexar. Once we have the base API complete (matching the RS CS 1.0 spec) we will evolve the API moving forward in Cactus and beyond.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Ideally, we would get folks excited about pushing the OpenStack API forward and this is where the innovation and evolution will occur. It has become obvious that a lack of stated direction about the OS API has led to some confusion, hence a stab at setting a roadmap through Cactus in this RFC. Two major events need to be happen and be clearly groked by the community; 1) The basis for the OpenStack API needs to transfer ownership to OpenStack from Rackspace. This will happen this month, and 2) The OpenStack API needs a clearly defined mechanism for presenting varying degrees of functionality. Clouds based on Nova will have a core set of required functions, and a myriad of optional components. In order to present a well designed and thought out programming model it is imperative that an extension and discovery mechanism be added, in addition to versioning (which is heavy-weight). The extension mechanism is planned to show up in Cactus.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>-John<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Christopher MacGown [mailto:ignoti@gmail.com] <br><b>Sent:</b> Thursday, December 30, 2010 5:28 PM<br><b>To:</b> John Purrier<br><b>Cc:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] [RFC] OpenStack API<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi guys,<o:p></o:p></p><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p>It is clearly important to establish a viable OpenStack Compute API by the Bexar timeframe. We started the implementation in Austin based on the Rackspace Cloud Servers 1.0 API, now we need to finish the work. The Austin work is half finished since we could not create and promote the OpenStack namespace and still required eucatools to set up and manage a cluster. Presented for comment is an approach for handling the OpenStack API for Bexar and Cactus. Additionally, this sets a path for the handoff of the API specification from Rackspace to OpenStack and the Rackspace Cloud transition to the OpenStack API.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I've been away in Europe and not as active as I'd like to have been in OpenStack development because of it. This thread concerns me though. When I was asked to present the API discussion at the Austin Summit, the only thing I was told I had to say was that the Rackspace API was becoming the "canonical" OpenStack one, and that the development of the Amazon API would continue. So, after my explaining the differences between the OpenStack API and the Amazon one, the first thing the discussion did was turn to namespacing and non-standard APIs. From the first summit, the community at the discussion wanted an ecosystem of APIs to compete with each other and the "blessed" ones. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I know the goal is to have an API wholly owned by the project that can be used to allow third-parties to use their already existing software with the project, considering the disparity of size between the OpenStack user-base and the largest competitor, does it make sense to focus development on the Rackspace API? How many of their customers actually use their API (as opposed to applications that are just an update away from supporting another one (for instance cyberduck or any of Mike Mayo's apps))? If even 1000% of the Rackspace cloud userbase used the API, it would be a drop in the bucket in comparison. So slowing down development of competing APIs (that could be promoted to canonical ones if they're more popular/better/more aesthetic/whatever…) seems a waste of community resources.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>tl;dr - Slowing down development of competing APIs is short-sighted.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Christopher<o:p></o:p></p></div></div></div></body></html>