Open Stack

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?
 
-----Original Message-----
From: "Ewan Mellor" <Ewan.Mellor at eu.citrix.com>
Sent: Thursday, March 3, 2011 4:29pm
To: "Eric Day" <eday at oddments.org>
Cc: "Brian Waldon" <brian.waldon at rackspace.com>, "openstack at lists.launchpad.net" <openstack at 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:eday at oddments.org]
> Sent: 03 March 2011 19:35
> To: Ewan Mellor
> Cc: Brian Waldon; openstack at 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.com at lists.launchpad.net
> > > [mailto:openstack-
> bounces+ewan.mellor=citrix.com at lists.launchpad.net]
> > > On Behalf Of Eric Day
> > > Sent: 03 March 2011 17:21
> > > To: Brian Waldon
> > > Cc: openstack at 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 at lists.launchpad.net
> > > > Unsubscribe : https://launchpad.net/~openstack
> > > > More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~openstack
> > > Post to     : openstack at lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110303/781dbf6a/attachment.html>