[Openstack] Multiple Versions in Openstack API

Brian Lamar brian.lamar at rackspace.com
Fri Mar 4 17:28:49 UTC 2011


Unfortunately v1.0 -> v1.1 is not a minor version increase (despite the names).

> then if the v1.1 servers/ endpoint only *extends* the 1.0 version
> /servers endpoint and doesn't break it, then you could have:

This works for minor versions, but not major versions which have different object formattings, a set of different top-level objects, and tons of other inconsistencies.

IMO your method works fine for minor versions, but not between major/breaking versions. We can still do v10 and v11 modules, but I would steer away from thinking there is any sort of link between them except for some supporting libraries.

-----Original Message-----
From: "Jay Pipes" <jaypipes at gmail.com>
Sent: Friday, March 4, 2011 12:17pm
To: "Eric Day" <eday at oddments.org>
Cc: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
Subject: Re: [Openstack] Multiple Versions in Openstack API

On Thu, Mar 3, 2011 at 12:20 PM, Eric Day <eday at oddments.org> wrote:
> 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).

+20.

Once an API is "done", we shouldn't need to modify the code, and code
"clutter" will only come into being if we try to put all versions in
the same controller class. If we instead do something like this, it
should be easy to maintain and code new versions of the API (and,
importantly, to test different versions of the API):

/nova/api/openstack/servers/v10.py
/nova/api/openstack/servers/v11.py

then if the v1.1 servers/ endpoint only *extends* the 1.0 version
/servers endpoint and doesn't break it, then you could have:

# in /nova/api/openstack/servers/v10.py

class Controller(wsgi.Controller):
    ...
    def index(...):
        ...
    def show(...):
        ...

# and in /nova/api/openstack/servers/v11.py
from nova.api.openstack.servers import v10

class Controller(v10. Controller):
    # Add more methods that v10 controller doesn't have...
    def reset_root_password():
        ...

Note that I'm not sure if reset_root_password is in the real 1.0 spec
or the 1.1 spec, but I hope you get my point...

-jay

_______________________________________________
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






More information about the Openstack mailing list