← Back to team overview

openstack team mailing list archive

Re: 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@xxxxxxxxxxxxxxxxxxx
> > [mailto:openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> > On Behalf Of Eric Day
> > Sent: 03 March 2011 17:21
> > To: Brian Waldon
> > Cc: openstack@xxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~openstack
> > > More help   : https://help.launchpad.net/ListHelp
> > 
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp



Follow ups

References