<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>I wanted to put out into the open where we think the evolution of the apis will go over the next few releases. This is by no means the only way to do this, but I thought it would be a start of conversation. </div>
<div><br>
</div>
<div><a href="http://wiki.openstack.org/api_transition">http://wiki.openstack.org/api_transition</a></div>
<div><br>
</div>
<div>I also wanted to clear up some confusion that I think came out of our email thread the other day. With the OpenStack 1.1 API proposal, this is really a OpenStack Compute 1.1 proposal. While volumes and images are currently in, I think longer term they
 would be pulled out. The network and volume services should be able to scale independently of each other. </div>
<div><br>
</div>
<div>If you look at the diagram, the changes would entail moving from an amqp protocol to a http protocol that a worker would hit on the public/admin interfaces to accomplish the same work as before. </div>
<div><br>
</div>
<div>Lets keep the thread going. </div>
<div><br>
</div>
<div>Pvo</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Justin Santa Barbara <<a href="mailto:justin@fathomdb.com">justin@fathomdb.com</a>><br>
<span style="font-weight:bold">Date: </span>Tue, 15 Feb 2011 11:38:37 -0800<br>
<span style="font-weight:bold">To: </span>Troy Toman <<a href="mailto:troy.toman@rackspace.com">troy.toman@rackspace.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Compute API 1.1<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
Sounds great - when the patch comes in we can discuss whether this should be an extension or whether scheduled snapshots / generic tasks have broader applicability across OpenStack (and thus would be better in the core API)
<div>
<div><br>
</div>
<div>Is there a blueprint?<br>
<br>
<br>
<br>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 11:32 AM, Troy Toman <span dir="ltr">
<<a href="mailto:troy.toman@rackspace.com">troy.toman@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br>
<div>
<div class="im">
<div>On Feb 15, 2011, at 1:06 PM, Justin Santa Barbara wrote:</div>
<br>
<blockquote type="cite">
<div>
<div style="word-wrap:break-word">
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; "><br>
</span></div>
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; ">OK - so it sounds like volumes are going to be in the core API (?) - good.  Let's get that into the API spec.  It also sounds like extensions (swift / glance?)
 are not going to be in the same API long-term.  So why do we have the extensions mechanism?</span></div>
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; "><br>
</span></div>
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; ">Until we have an implemented use case (i.e. a patch) that uses the extensions element, I don't see how we can spec it out or approve it.  So if you want it in
 v1.1, we better find a team that wants to use it and write code.  If there is such a patch, I stand corrected and let's get it reviewed and merged.</span></div>
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; "><br>
</span></div>
<div style="color:rgb(0, 0, 0)"><span style="font-size: 14px; font-family: Calibri, sans-serif; ">I would actually expect that the majority of the use cases that we want in the API but don't _want_ to go through core would be more simply addressed by well-known
 metadata (e.g. RAID-5, multi-continent replication, HPC, HIPAA).</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
<div>I'm don't agree that the lack of a coded patch means we can't discuss an extension mechanism. But, if you want a specific use case, we have at least one we intend to deliver. It may be more of a one-off than a general case because it is required to give
 us a reasonable transition path from our current codebase to Nova. But, it is not an imagined need.</div>
<div><br>
</div>
<div>In the Rackspace Cloud Servers 1.0 API, we support a concept of backup schedules with a series of API calls to manage them. In drafting the OpenStack compute API, this was something that didn't feel generally applicable or useful in the core API. So, you
 don't see it as part of the CORE API spec. That said, for transition purposes, we will need a way to provide this capability to our customers when we move to Nova. Our current plan is to do this using the extension mechanism in the proposed API.</div>
</div>
<div><br>
</div>
<div>If there is a better way to handle this need, then let's discuss further. But, I didn't want the lack of a specific example to squash the idea of extensions.</div>
<div><br>
</div>
<div>Troy Toman</div>
<div class="im"><br>
<pre>Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message. 
Your cooperation is appreciated.
</pre>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________ Mailing list: <a href="https://launchpad.net/~openstack">
https://launchpad.net/~openstack</a> Post to : <a href="mailto:openstack@lists.launchpad.net">
openstack@lists.launchpad.net</a> Unsubscribe : <a href="https://launchpad.net/~openstack">
https://launchpad.net/~openstack</a> More help : <a href="https://help.launchpad.net/ListHelp">
https://help.launchpad.net/ListHelp</a> </blockquote>
</span>
</body>
</html>