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