Open Stack

On Fri, Mar 4, 2011 at 1:33 PM, Brian Waldon <brian.waldon at rackspace.com> wrote:
> As Brian is temporarily out of the office, I'll answer for him. Here are a
> few (major-version) differences I see in the 1.1 spec:

OK. Either Brian is good ;)

> 1) marker keyword replaces offset for pagination (functionally different,
> not just a different name)

OK. This would mean that the current
nova.api.openstack.common.limited() function should move to be instead
a middleware class, say,
nova.api.openstack.limits.v10.LimitMiddleware, and that we can make a
v11.LimitMiddleware for the new 1.1 functionally-different limiter.

> 2) server addresses container structured differently

This is easily solved in the code I showed. Simply implement the
index()/show()/details() method to return the different structure.

> 3) all containers structured differently, now with links

Again, this can be solved by implementing methods differently (using
object-method overrides in the child class).

> 3) shared ip groups is removed

So, the shared IP methods of the 1.0 API are all in
/nova/api/openstack/shared_ip_groups.py. We would do the following:

* bzr mv nova/api/openstack/shared_ip_groups.py
nova/api/openstack/shared_ip_groups/v10.py
* cp nova/api/openstack/shared_ip_groups/v10.py
nova/api/openstack/shared_ip_groups/v11.py

Open nova/api/openstack/shared_ip_groups/v11.py and set ALL of the
Controller methods to raise faults.Fault(exc.HTTPNotImplemented()),
just as the Shared IP Groups controller currently does for update(),
delete(), and create():

    def create(self, req):
        """ Creates a new Shared IP group """
        raise faults.Fault(exc.HTTPNotImplemented())

-jay

>
>
>
> Waldon
>
>
>
> -----Original Message-----
> From: "Jay Pipes" <jaypipes at gmail.com>
> Sent: Friday, March 4, 2011 1:20pm
> To: "Brian Lamar" <brian.lamar at rackspace.com>
> Cc: "openstack at lists.launchpad.net" <openstack at lists.launchpad.net>
> Subject: Re: [Openstack] Multiple Versions in Openstack API
>
> On Fri, Mar 4, 2011 at 12:28 PM, Brian Lamar <brian.lamar at rackspace.com>
> wrote:
>> Unfortunately v1.0 -> v1.1 is not a minor version increase (despite the
>> names).
>
> Ah, ok.
>
>>> 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.
>
> Could you elaborate on an example of this inconsistency between 1.0
> and 1.1? That way, I'd have more to go on in thinking how to break
> the versioning into separate modules.
>
> Thanks Brian!
> 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