openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

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.Mellor@xxxxxxxxxxxxx>
>    Sent: Thursday, March 3, 2011 4:29pm
>    To: "Eric Day" <eday@xxxxxxxxxxxx>
>    Cc: "Brian Waldon" <brian.waldon@xxxxxxxxxxxxx>,
>    "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
>    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@xxxxxxxxxxxx]
>    > Sent: 03 March 2011 19:35
>    > To: Ewan Mellor
>    > Cc: Brian Waldon; openstack@xxxxxxxxxxxxxxxxxxx
>    > 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@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