<font face="arial" size="2"><p>So I also think it is great to support multiple apis (and major versions). Right now I am more concerned with how we should accomplish this in the code. Does anyone have any objection to creating a different directory under nova/api per api and major version with a common set of code shared between them?</p>
<p> </p>
<p>-----Original Message-----<br />From: "Ewan Mellor" <Ewan.Mellor@eu.citrix.com><br />Sent: Thursday, March 3, 2011 4:29pm<br />To: "Eric Day" <eday@oddments.org><br />Cc: "Brian Waldon" <brian.waldon@rackspace.com>, "openstack@lists.launchpad.net" <openstack@lists.launchpad.net><br />Subject: RE: [Openstack] Multiple Versions in Openstack API<br /><br /></p>
<div id="SafeStyles1299187855">
<p>That's fine by me. If you've got reasons to keep it, and upgrade from CloudServers 1.0 is a great one, then let's keep it.<br /><br />Ewan.<br /><br />> -----Original Message-----<br />> From: Eric Day [mailto:eday@oddments.org]<br />> Sent: 03 March 2011 19:35<br />> To: Ewan Mellor<br />> Cc: Brian Waldon; openstack@lists.launchpad.net<br />> Subject: Re: [Openstack] Multiple Versions in Openstack API<br />> <br />> If we are supporting ec2, we should support CloudServers 1.0 since<br />> there are tools for that. Rackspace needs to do it for their upgrade<br />> path, why not keep in in Nova trunk so others can use? It will be<br />> legacy just like the ec2 interface, but I see no harm in keeping<br />> it there.<br />> <br />> If the underlying service changes enough that we can't (or would need<br />> to jump through too many hoops), we can discuss specifics then and<br />> possibly remove it.<br />> <br />> -Eric<br />> <br />> On Thu, Mar 03, 2011 at 07:19:58PM +0000, Ewan Mellor wrote:<br />> > I agree with you in general, Eric.<br />> ><br />> > For this particular transition (API 1.0 to 1.1) are there any<br />> important client tools that would break? I don't imagine that there<br />> are many people who've written against Bexar and wouldn't be able to<br />> redo their stuff against Cactus, so the question is really whether<br />> there are Cloud Servers clients that we expect to retarget against<br />> Cactus without change.<br />> ><br />> > The reason I'm asking is that this particular transition seems to be<br />> much less incremental than others may be in the future, and if we can<br />> shed the burden now, we may as well. We certainly won't be able to<br />> shed the burden in the future.<br />> ><br />> > Thanks,<br />> ><br />> > Ewan.<br />> ><br />> > > -----Original Message-----<br />> > > From: openstack-bounces+ewan.mellor=citrix.com@lists.launchpad.net<br />> > > [mailto:openstack-<br />> bounces+ewan.mellor=citrix.com@lists.launchpad.net]<br />> > > On Behalf Of Eric Day<br />> > > Sent: 03 March 2011 17:21<br />> > > To: Brian Waldon<br />> > > Cc: openstack@lists.launchpad.net<br />> > > Subject: Re: [Openstack] Multiple Versions in Openstack API<br />> > ><br />> > > We should support old versions. The API layers should be a very<br />> thin<br />> > > layer over what the Nova internal API provides, so even if we have<br />> > > v1.0, v1.1, etc. subdirectories in the API and do full code<br />> copying,<br />> > > it should be a fairly minimal mapping. We can of course share as<br />> > > much common code (like serialization) between them to keep code<br />> > > duplication down. Think of all the tools that folks will write that<br />> > > won't get the immediate attention when we decide to change. I'm not<br />> > > going to propose how to deprecate really old versions, we'll tackle<br />> > > that when we get there (probably years away).<br />> > ><br />> > > -Eric<br />> > ><br />> > > On Wed, Mar 02, 2011 at 05:42:41PM -0500, Brian Waldon wrote:<br />> > > > Currently, the Openstack API includes a Versions WSGI<br />> application.<br />> > > The<br />> > > > intended purpose is to detail all versions of the API that are<br />> > > reachable<br />> > > > by a client. Currently, it only supports "v1.0." As we move<br />> > > towards the<br />> > > > Cactus release, we need to add support for the new "v1.1"<br />> > > specification.<br />> > > > The intention of the Versions app seems to be to deploy<br />> multiple<br />> > > versions<br />> > > > of the OS API within the same codebase. Since these two<br />> versions<br />> > > have<br />> > > > significant differences, having to support each in the same<br />> code<br />> > > seems<br />> > > > unnatural.<br />> > > ><br />> > > > A<br />> > > ><br />> > > > With the existing approach, versioning could be accomplished<br />> > > multiple<br />> > > > ways: version-specific "if" statements, version-specific class<br />> > > > hierarchies, etc. I feel this is inelegant and could be<br />> > > accomplished a<br />> > > > much cleaner way. I propose we move the responsibilities of<br />> the<br />> > > Versions<br />> > > > app out of the nova codebase and into the hands of the<br />> operator of<br />> > > the api<br />> > > > endpoints. With this approach, the code would not<br />> unnecessarily<br />> > > increase<br />> > > > in complexity as more versions of the api are released. The<br />> major<br />> > > drawback<br />> > > > of this strategy is that each release of Openstack Compute<br />> could<br />> > > support a<br />> > > > single OS API version.<br />> > > ><br />> > > > A<br />> > > ><br />> > > > As we are slated to have our first multi-version OS API<br />> release in<br />> > > Cactus,<br />> > > > I would like to see us reach a consensus as soon as posible.<br />> Any<br />> > > and all<br />> > > > feedback is welcome!<br />> > > ><br />> > > > A<br />> > > ><br />> > > > Brian Waldon<br />> > ><br />> > > > _______________________________________________<br />> > > > Mailing list: https://launchpad.net/~openstack<br />> > > > Post to : openstack@lists.launchpad.net<br />> > > > Unsubscribe : https://launchpad.net/~openstack<br />> > > > More help : https://help.launchpad.net/ListHelp<br />> > ><br />> > ><br />> > > _______________________________________________<br />> > > Mailing list: https://launchpad.net/~openstack<br />> > > Post to : openstack@lists.launchpad.net<br />> > > Unsubscribe : https://launchpad.net/~openstack<br />> > > More help : https://help.launchpad.net/ListHelp</p>
</div></font>