<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; ">
<div>I think I understand your confusing Justin.  Extensions are not there to bind APIs together.  The examples I gave were probably a bit misleading.  Extensions are there to support niche functionality and to allow developers to innovate without having to
 wait for some centralized group to approve.</div>
<div><br>
</div>
<div>You're right,  things should become clearer as we move towards code :-)</div>
<div><br>
</div>
<div>-jOrGe W.</div>
<div><br>
</div>
<br>
<div>
<div>On Feb 18, 2011, at 5:08 PM, Justin Santa Barbara wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>I find this even more confusing than before.  On the one hand, we talk about a suite of independent APIs, and on the other hand we talk about binding them together using extensions.  We talk about standardizing around one API, and we talk about letting
 a thousand flowers bloom as extensions.</div>
<div><br>
</div>
<div>I'm going to wait till there's concrete code here before commenting further, I think, so that we can talk in specifics.</div>
<div><br>
</div>
<div>Justin</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at 2:32 PM, Erik Carlin <span dir="ltr">
<<a href="mailto:erik.carlin@rackspace.com">erik.carlin@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>The way I see it, there isn't a singular OpenStack API (even today there is swift, nova, and glance).  OpenStack is a suite of IaaS each with their own API – so there is a SUITE of standard OS APIs.  And each OS service should strive to define the canonical
 API for automating that particular service.  If I just want to run an image repo, I deploy glance.  If my SAN guy can't get storage provisioned fast enough, I deploy the OS block storage service (once we have it).  And if I want a full cloud suite, I deploy
 all the services.  They are loosely coupled and (ideally) independent building blocks.  Whether one chooses to front the different service endpoints with a proxy to unify them or have separate service endpoints is purely a deployment decision.  Either way,
 there are no competing OS APIs.  Support for 3rd party APIs (e.g. EC2) is secondary IMO, and to some degree, detrimental.  Standards are defined largely in part by ubiquity.  We want OS to become ubiquitous and we want the OS APIs to become defacto.  Supporting
 additional APIs (or even variations of the same API like AMQP per the other thread) doesn't help us here.  I would love to see the community rally behind a per service standard OS REST API that we can own and drive.  </div>
<div><br>
</div>
<div>To that end, the goal as I see it is to launch canonical OpenStack Compute (nova) and Image (glance) APIs with Cactus.  In Diablo, we would then work to introduce separate network and block storage services with REST APIs as well.  All APIs would be independently
 versioned and stable.  I'm ALL for per language OpenStack bindings that implement support for the entire suite of services.</div>
<div><br>
</div>
<div>Re: extensions, it's actually the technical aspects that are driving it.  There is a tension between standards and innovation that needs to be resolved.  In addition, we need to be able to support niche functionality (e.g. Rackspace may want to support
 API operations related to managed services) without imposing it on everyone.  These problems are not new.  We've seen the same exact thing with OpenGL and they have a very successful extension model that has solved this.  Jorge studied this when did his PhD
 and has designed extensions with that in mind.  He has a presentation on extensions
<a>here</a> if you haven't seen it.  I think extensions are critically important and would encourage dialog amongst the community to come to a consensus on this.  Per my points above, I would prefer to avoid separate APIs for the same service.  Let's see if
 we can get behind a per service API that becomes THE defacto standard way for automating that service.</div>
<div><br>
</div>
<div>Erik</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>
</div>
<span style="font-weight:bold">Date: </span>Fri, 18 Feb 2011 09:57:12 -0800
<div class="im"><br>
<span style="font-weight:bold">To: </span>Paul Voccio <<a href="mailto:paul.voccio@rackspace.com" target="_blank">paul.voccio@rackspace.com</a>><br>
</div>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>>
<div>
<div></div>
<div class="h5"><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Compute API 1.1<br>
</div>
</div>
</div>
<div>
<div></div>
<div class="h5">
<div><br>
</div>
<span style="font-size:14px;border-collapse:collapse;font-family:Calibri, sans-serif">> How is the 1.1 api proposal breaking this? </span>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px"><br>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">Because if we launch an OpenStack API, the expectation is that this will be the OpenStack API :-)</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px"><br>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">If we support a third-party API (CloudServers or EC2), then people will continue to use their existing wrappers (e.g. jclouds)  Once there's an OpenStack API, then end-users
 will want to find a library for that, and we don't want that to be a poor experience.  To maintain a good experience, we either can't break the API, or we need to write and maintain a lot of proxying code to maintain compatibility.  We know we're not ready
 for the first commitment, and I don't think we get enough to justify the second. </span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">  </span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">
<div>> I think the proxy would make sense if you wanted to have a single api. Not all service providers will but I see this as entirely optional, not required to use the services. </div>
<div><br>
</div>
<div>But then we have two OpenStack APIs?  Our ultimate end users don't use the API, they use a wrapper library.  They want a stable library that works and is kept up to date with recent changes and don't care about what's going on under the covers.  Wrapper
 library authors want an API that is (1) one API and (2) stable with reasonable evolution, otherwise they'll abandon their wrapper or not update it.</div>
<div><br>
</div>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">> The extensions mechanism is the biggest change, iirc. </span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px"><br>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px">I'm not a big fan of the extensions idea, because it feels more like a reflection of a management goal, rather than a technical decision ("OpenStack is open to extensions")
  Supporting separate APIs feels like a better way to do that.  I'm very open to be corrected here, but I think we need to see code that wants to use the extension API and isn't better done as a separate API.  Right now I haven't seen any patches, and that
 makes me uneasy.</span></font></div>
<div><font face="Calibri,sans-serif"><span style="border-collapse:collapse;font-size:14px"><br>
</span></font></div>
<div><br>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at 9:29 AM, Paul Voccio <span dir="ltr">
<<a href="mailto:paul.voccio@rackspace.com" target="_blank">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>The spec for 1.0 and 1.1 are pretty close. The extensions mechanism is the biggest change, iirc. </div>
<div><br>
</div>
<div>I think the proxy would make sense if you wanted to have a single api. Not all service providers will but I see this as entirely optional, not required to use the services. </div>
<div><br>
</div>
<div>The push to get a completed compute api is the desire move away from the ec2 api to something that we can guide, extend and vote on as a community. The sooner we do the the better. </div>
<div><br>
</div>
<div>How is the 1.1 api proposal breaking this? </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">
<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>Fri, 18 Feb 2011 09:10:19 -0800<br>
<span style="font-weight:bold">To: </span>Paul Voccio <<a href="mailto:paul.voccio@rackspace.com" target="_blank">paul.voccio@rackspace.com</a>><br>
<span style="font-weight:bold">Cc: </span>Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>, "<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a>>
<div><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Compute API 1.1<br>
</div>
</div>
<div>
<div></div>
<div>
<div><br>
</div>
<blockquote style="border-left:#b5c4df 5 solid;padding:0 0 0 5;margin:0 0 0 5">Jay: The AMQP->REST was the re-architecting I was referring to, which would not be customer-facing (other than likely introducing new bugs.)  Spinning off the services, if this is
 visible at the API level, is much more concerning to me.
<div><br>
</div>
<div>So Paul, I think the proxy is good because it acknowledges the importance of keeping a consistent API.  But - if our API isn't finalized - why push it out at all, particularly if we're then going to have the overhead of maintaining another translation
 layer?  For Cactus, let's just support EC2 and/or CloudServers 1.0 API compatibility (again a translation layer, but one we probably have to support anyway.)  Then we can design the right OpenStack API at our leisure and meet all of our goals: a stable Cactus
 and stable APIs.  If anyone ends up coding to a Cactus OpenStack API, we shouldn't have them become second-class citizens 3 months later.</div>
<div><br clear="all">
Justin<br>
<br>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at 6:31 AM, Paul Voccio <span dir="ltr">
<<a href="mailto:paul.voccio@rackspace.com" target="_blank">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">
Jay,<br>
<br>
I understand Justin's concern if we move /network and /images and /volume<br>
to their own endpoints then it would be a change to the customer. I think<br>
this could be solved by putting a proxy in front of each endpoint and<br>
routing back to the appropriate service endpoint.<br>
<br>
I added another image on the wiki page to describe what I'm trying to say.<br>
<div><a href="http://wiki.openstack.org/api_transition" target="_blank">http://wiki.openstack.org/api_transition</a><br>
<br>
</div>
I think might not be as bad of a transition since the compute worker would<br>
receive a request for a new compute node then it would proxy over to the<br>
admin or public api of the network or volume node to request information.<br>
It would work very similar to how the queues work now.<br>
<br>
pvo<br>
<div>
<div></div>
<div><br>
On 2/17/11 8:33 PM, "Jay Pipes" <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<br>
>Sorry, I don't view the proposed changes from AMQP to REST as being<br>
>"customer facing API changes". Could you explain? These are internal<br>
>interfaces, no?<br>
><br>
>-jay<br>
><br>
>On Thu, Feb 17, 2011 at 8:13 PM, Justin Santa Barbara<br>
><<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>> wrote:<br>
>> An API is for life, not just for Cactus.<br>
>> I agree that stability is important.  I don't see how we can claim to<br>
>> deliver 'stability' when the plan is then immediately to destablize<br>
>> everything with a very disruptive change soon after, including customer<br>
>> facing API changes and massive internal re-architecting.<br>
>><br>
>><br>
>> On Thu, Feb 17, 2011 at 4:18 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
>>><br>
>>> On Thu, Feb 17, 2011 at 6:57 PM, Justin Santa Barbara<br>
>>> <<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>> wrote:<br>
>>> > Pulling volumes & images out into separate services (and moving from<br>
>>> > AMQP to<br>
>>> > REST) sounds like a huge breaking change, so if that is indeed the<br>
>>>plan,<br>
>>> > let's do that asap (i.e. Cactus).<br>
>>><br>
>>> Sorry, I have to disagree with you here, Justin :)  The Cactus release<br>
>>> is supposed to be about stability and the only features going into<br>
>>> Cactus should be to achieve API parity of the OpenStack Compute API<br>
>>> with the Rackspace Cloud Servers API. Doing such a huge change like<br>
>>> moving communication from AMQP to HTTP for volume and network would be<br>
>>> a change that would likely undermine the stability of the Cactus<br>
>>> release severely.<br>
>>><br>
>>> -jay<br>
>><br>
>><br>
<br>
<br>
<br>
</div>
</div>
<div>
<div></div>
<div>Confidentiality Notice: This e-mail message (including any attached or<br>
embedded documents) is intended for the exclusive and confidential use of the<br>
individual or entity to which this message is addressed, and unless otherwise<br>
expressly indicated, is confidential and privileged information of Rackspace.<br>
Any dissemination, distribution or copying of the enclosed material is prohibited.<br>
If you receive this transmission in error, please notify us immediately by e-mail<br>
at <a href="mailto:abuse@rackspace.com" target="_blank">abuse@rackspace.com</a>, and delete the original message.<br>
Your cooperation is appreciated.<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</span>
<div>
<div></div>
<div>
<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>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________ 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> </span></div>
</blockquote>
</div>
<br>
</div>
_______________________________________________<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>
</blockquote>
</div>
<br>
</body>
</html>