openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On Fri, Mar 4, 2011 at 2:55 PM, Brian Waldon <brian.waldon@xxxxxxxxxxxxx> wrote:
> While a middleware solution for the "limited" functionality would
> technically work, I think most of us would agree it should not be
> implemented as middleware. It can be done much more efficiently at the
> datastore level, especially with the introduction of "marker".

All the middleware would do is populate an offset and limit value in
the request environs passed to the next piece of the WSGI pipeline.
The datastore would then take these values when it looked up the
elements to return. The 1.1 changes to the limiting functionality
would be implemented as a middleware that looked for the "marker" and
populated the offset and limit values that the lower-down datastore
access would use.

When I say middleware, I'm referring to WSGI middleware in the Python
world, not anything else.

> As for shared_ip_groups, I wouldn't want to implement an essentially blank
> controller. I would just leave it out and not expose it through the router.
>
> While I do think we can make multiple versions live together in trunk, I
> would rather see the directory structure like the following. We would put
> the existing code in common/ and things like shared_ip_groups.py in v10
> only. We would have a servers controller in all three folders, since they
> have common functionality but still some version-specific differences.
>
> /nova/api/openstack/common/
>
> /nova/api/openstack/v10/
>
> /nova/api/openstack/v11/

Sure, no disagreement from me there... my code was to spark some
discussion, not necessarily to be the end result :)

-jay

> Waldon
>
>
>
> -----Original Message-----
> From: "Jay Pipes" <jaypipes@xxxxxxxxx>
> Sent: Friday, March 4, 2011 2:08pm
> To: "Brian Waldon" <brian.waldon@xxxxxxxxxxxxx>
> Cc: "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx>,
> "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Openstack] Multiple Versions in Openstack API
>
> On Fri, Mar 4, 2011 at 1:33 PM, Brian Waldon <brian.waldon@xxxxxxxxxxxxx>
> 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@xxxxxxxxx>
>> Sent: Friday, March 4, 2011 1:20pm
>> To: "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx>
>> Cc: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
>> Subject: Re: [Openstack] Multiple Versions in Openstack API
>>
>> On Fri, Mar 4, 2011 at 12:28 PM, Brian Lamar <brian.lamar@xxxxxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp