<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</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>Thoughts below</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>Mon, 14 Feb 2011 15:40:04 -0800<br>
<span style="font-weight:bold">To: </span>Paul Voccio <<a href="mailto:paul.voccio@rackspace.com">paul.voccio@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;">
Ah - well, I was sort of expecting that we'd all go the other way and agree some core functionality, and I thought that volumes should definitely be part of that. I'd hope that the core functionality would always be part of the core API, and I'd include images
& volumes in that list.</blockquote>
</span>
<div><br>
</div>
<div>I'm all for having the discussion. How would this work if someone didn't run a volume service or glance? Should the api listen for that? I don't disagree that there should be core apis for each service, but that in the long run, there may not be a single
api. Glance already doesn't have an api in the openstack 1.1 spec. What about Swift? </div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>I think that building an extensible API is an ambitious proposition. AWS seems to have some pretty rough edges in their API because they've built everything incrementally, and I would hope that we could do better, even if it does mean 'big design up front'.</div>
</blockquote>
</span><span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div>I think the block storage / volumes, networking, images and compute should all be part of the core API and should work well together.
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Of course they <span style="font-weight: bold">all</span> have to work well together. I do think we need to discuss how it works when someone isn't using these services. It is an OS API implementation then? </div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div> We shouldn't be relying on extensions for Cactus. In fact, I'd rather leave out extensions until we have a solid use case. You may be saying that volumes will be our test-use case, but I think that will yield a sub-optimal API.</div>
<div><br>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>I see extensions doing a few things. First, it gives a way for other developers to work on and promote additions to the api without fighting to get them into core at first. Can you explain how it would yield a sub-optimal api? </div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div><br>
</div>
<div><br>
</div>
<div>With regards to the difference between the CloudServers API and the OpenStack API, I really do think there should be separate documents. I'd like for the OpenStack API to basically just have the JSON & XML interfaces in there, and none of the operational
stuff that Rackspace needs to do to operate a public cloud (such as caching) That is important stuff, but we need to divide and conquer. I'd also like to see a third document, by NASA/Anso, which describes a deployment profile for a private cloud (probably
no caching or rate limits). I think the division will actually help us here</div>
</blockquote>
</span>
<div> </div>
<div>I think we would want to have the same operational aspects in both public and private clouds. It gives consistent experience between what is deployed in a smaller implementation between what is deployed in large implementations. What we should do is make
these levers very easy to find and tune. Maybe the default is they are tuned to high defaults when deployed, but the functionality should ship in the api. </div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>- I don't think anyone will argue with Rackspace's expertise on their deployment needs, nor with NASA's on theirs, and we can just have the core behavior in the OpenStack API spec.</div>
<div><br clear="all">
Justin<br>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 14, 2011 at 3:18 PM, Paul Voccio <span dir="ltr">
<<a href="mailto:paul.voccio@rackspace.com">paul.voccio@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;color:rgb(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif">
<div>Justin - </div>
<div><br>
</div>
<div>Thought some more on your comments wrt images being in the 1.1 api spec. I agree with you that it doesn't make sense in the long term to have them in the compute api since the service will delegate to glance in the long term. I would propose that in the
1.2 or other future spec that /images move to an action on /compute since that’s really what is happening. I don't know that it makes sense to do so in 1.1 as changes are contentious enough without being a total rewrite. </div>
<div><br>
</div>
<div>Looking forward to your feedback,</div>
<div>pvo</div>
<div><br>
</div>
<span>
<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">
<div class="im"><span style="font-weight:bold">From: </span>Justin Santa Barbara <<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>><br>
<span style="font-weight:bold">Date: </span>Mon, 14 Feb 2011 14:32:52 -0800<br>
</div>
<div class="im"><span style="font-weight:bold">To: </span><<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>><br>
</div>
<div class="im"><span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Compute API 1.1<br>
</div>
</div>
<div><br>
</div>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5">
<div>
<div></div>
<div class="h5">
<div>Some thoughts...</div>
<div><br>
</div>
<div>General:</div>
<div><br>
</div>
<div>
<ul>
<li>Are we writing the OpenStack API, or are we writing the document for the next version of Cloud Servers? In my opinion, the two need to be separate. For example, specifications of resource limits and rate limits, supported compression encodings, timeout
on persistent connections, pagination, caching, polling and resize confirmation windows don't belong in the core OpenStack API. These should be put in the CloudServers v1.1 documentation, but a different OpenStack provider will not impose the same limitations
that Rackspace will.</li></ul>
</div>
<div><br>
</div>
Metadata:
<div><br>
</div>
<div>
<ul>
<li>The 5 item limit will probably need to be raised if we start using the metadata for hints etc, but this is no big deal</li><li>What is the behaviour of the metadata collection update when metadata is already present (merge or replace)? Can this return the new metadata values instead of no-return-value?</li><li>Should we allow custom metadata on all items? Should we replace some properties with well-known metadata? e.g. on flavors, should the disk property move to openstack:disk metadata? This way we don't need to define the exact set of metadata on all items
for eternity (e.g. authors on extensions)</li><li>Are duplicate metadata keys allowed?</li><li>Can we please reserve the openstack: prefix, just like AWS reserves the aws: prefix</li></ul>
</div>
<div><br>
</div>
<div>IP Addresses:</div>
<div><br>
</div>
<div>
<ul>
<li>Instead of just supporting a public and private network, how about specifying <network id="public"> and <network id="private">. This way we can also support more networks e.g. SAN, private VPN networks, HPC interconnects etc</li><li>Is it useful to know which IPV4 addresses and IPV6 addresses map to network cards? Right now if there are multiple addresses on the same network, the correspondence is undefined.</li><li>What happens when a machine has a block of addresses? Is each address listed individually? What happens in IPv6 land where a machine could well have a huge block? I think we need a netmask.</li></ul>
</div>
<div><br>
</div>
<div>Extensions:</div>
<div><br>
</div>
<div>
<ul>
<li>How are the XML schemas going to work with extension elements? Right now, it's very free-form, which can cause problems with useful schemas. Are the proposed schemas available?</li></ul>
</div>
<div><br>
</div>
<div>Volumes:</div>
<div><br>
</div>
<div>
<ul>
<li>Volume support is core to OpenStack (and has been since launch). This needs therefore to be in the core API, not in an extension. Or if it is an extension then compute, images and flavors should all be in extensions also (which would be cool, if a little
complicated.)</li></ul>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>Justin</div>
<div><br>
</div>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 14, 2011 at 11:30 AM, John Purrier <span dir="ltr">
<<a href="mailto:john@openstack.org" target="_blank">john@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p>Bumping this to the top of the list. One of the key deliverables for Cactus is a complete and usable OpenStack Compute API. This means that using only the API and tools that interact with the OpenStack Compute API Nova can be installed and configured; once
running all of the Nova features and functions for VM, Network, and Volume provisioning and management are accessible and operable through the API.</p>
<p> </p>
<p>We need your eyes on this, to ensure that the spec is correct. Please take the time to review and comment, the more up-front work we do here the better the implementation will be.</p>
<p> </p>
<p>Thanks,</p>
<p> </p>
<p>John</p>
<p> </p>
<p>-----Original Message-----<br>
From: openstack-bounces+john=<a href="http://openstack.org" target="_blank">openstack.org</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a> [mailto:<a href="mailto:openstack-bounces%2Bjohn" target="_blank">openstack-bounces+john</a>=<a href="http://openstack.org" target="_blank">openstack.org</a>@<a href="http://lists.launchpad.net" target="_blank">lists.launchpad.net</a>]
On Behalf Of Gabe Westmaas<br>
Sent: Wednesday, February 09, 2011 3:03 PM<br>
To: <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Subject: [Openstack] OpenStack API 1.1</p>
<p> </p>
<p>A blueprint and proposed spec for OpenStack API 1.1 has been posted and I would love to get feedback on the specification.</p>
<p> </p>
<p>Blueprint:</p>
<p><a href="https://blueprints.launchpad.net/nova/+spec/openstack-api-1-1" target="_blank">https://blueprints.launchpad.net/nova/+spec/openstack-api-1-1</a></p>
<p> </p>
<p>Spec wiki:</p>
<p><a href="http://wiki.openstack.org/OpenStackAPI_1-1" target="_blank">http://wiki.openstack.org/OpenStackAPI_1-1</a></p>
<p> </p>
<p>Detailed Spec:</p>
<p><a href="http://wiki.openstack.org/OpenStackAPI_1-1?action=AttachFile&do=view&target=c11-devguide-20110209.pdf" target="_blank">http://wiki.openstack.org/OpenStackAPI_1-1?action=AttachFile&do=view&target=c11-devguide-20110209.pdf</a></p>
<p> </p>
<p>We'd like to finish up as much of the API implementation for cactus as possible, and in particular we want to make sure that we get API extensions correct as early as possible. Other new features in the 1.1 spec include the ability to view both IPv4 and
v6 addresses, migration to the OpenStack namespace and moving from image IDs in responses to URIs (imageRef) for the image. There may be some additional changes as well, please jump in if I missed some.</p>
<p> </p>
<p>I will add details to the wiki page as needed based on discussions on the mailing list.</p>
<p> </p>
<p>Thanks, and let me know if you have questions.</p>
<p> </p>
<p>Gabe</p>
<p> </p>
<p> </p>
<p>_______________________________________________</p>
<p>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a></p>
<p>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a></p>
<p>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a></p>
<p>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a></p>
</div>
</div>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<div class="im">_______________________________________________ Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">
https://launchpad.net/~openstack</a> Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">
openstack@lists.launchpad.net</a> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">
https://launchpad.net/~openstack</a> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">
https://help.launchpad.net/ListHelp</a> </div>
</blockquote>
</span>
<div class="im">
<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>
</blockquote>
</span>
<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 abuse@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE></body>
</html>