Open Stack

Hi,

I've looked at this patch - as apparently my role is the API police man :)
Kudos to Akihiro for beating me at it!

Before dwelling into details about bw compability, let me say that what
Alex has proposed is what already happens on all major openstack projects.
I think Alex provided enough justification already for why this patch does
not break clients written for Quantum v2 API; what I am concerned about is
the other part of the backward compatibility: the plugin interface.

You're changing it quite a lot - but not changing QuantumPluginBaseV2. This
should not happen. Keep in mind there might be also out-of-source tree
plugins, and we don't want to break them.
The plugin interface is a contract which almost as important as the API
spec. Also, your patch will need quite an extensive testing, as we need
make sure that there are no side-effects on in-source plugins (so if you
care about a particular plugin you'd better check this patch!).


I still not sure about the best course of action. I see the following
options, and your feedback would be welcome:
1) Don't break the plugin interface and move pagination to API 2.1. Decide
whether support them both.
2) Allow plugins to declare whether they support or not pagination. If not,
return an error code, and document it in the API spec.
3) Just like 2, but emulate pagination in the API layer (which might
inefficient).

Some more comments inline.

On 8 November 2012 16:16, Xu He Jie <xuhj at linux.vnet.ibm.com> wrote:

> On 2012年11月08日 14:46, Akihiro MOTOKI wrote:
>
>> Alex, Quantum folks,
>>
>> Thanks for working on pagination support in Quantum.
>> The design docs is very detail and code looks almost good.
>>
> Akihiro, Thank you for the reply!
>
>  When adding pagination support, we also need to consider
>> API v2.0 backward compatibility. According to your proposal
>> at least the following points will be changed.
>> - Not all items are returned in one listing operation
>>    (All items are returned in the current v2.0 API)
>>
>
> We have option 'max_limit' in quantum.conf. We can specific a special
> value(example: -1) for
> disable pagination. And if user didn't add 'limit' params in the url, all
> items are returned in one
> list operation. So pagination will be a optional feature. If user want to
> use it, just add 'limit' params
> in url.


This is the behaviour of all the openstack projects that do pagination. To
ensure backward compatibility it is important that this parameter stays as
a maximum value, and not a default value.
-1 then does not mean "disable" pagination. It should mean "no limit".


>
>
>  - Pagination link is added in the response.
>>
>
> When user didn't specific a limit value, we don't show the pagination
> links.


Agreed.


>
>
>> Should we change v2.0 API to support pagination, or keep v2.0 API
>> unchanged
>> and add pagination support in the next version of API (v2.1)?
>>
>
> In next version, we can specific a default limit value. Then force limit
> the maximum of items
> are returned in one operation.


It is still too early to decide if we actually want to enforce a default
limit in the next API release, and is probably not very relevant too.


>
>
>
>> Before reviewing the patch in gerrit, it is better to clarify this point.
>>
>> Any idea?
>>
>> Thanks,
>> Akihiro Motoki
>>
>>  Date: Wed, 31 Oct 2012 15:31:39 +0800
>>>>>>> From: Xu He Jie <xuhj at linux.vnet.ibm.com>
>>>>>>> Subject: [openstack-dev] [Quantum] Support pagination in api v2.0
>>>>>>>
>>>>>> Hi, forks,
>>>
>>> I am working on the blueprint 'Support pagination in api v2.0':
>>> https://blueprints.launchpad.**net/ <https://blueprints.launchpad.net/>
>>> quantum/+spec/support-**pagination-in-api-v2
>>>
>>> I finished spec document. Now the blueprint turn 'Definition' to
>>> 'Discussion' status. I write spec
>>> document in google doc, you can comment in google doc or reply this
>>> mail. I will appreciate for
>>> any comment!
>>>
>>> Happy to join the team!
>>>
>>> Thanks!
>>> Alex Xu
>>>
>>>
>>>  ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121110/fe51c9a3/attachment.html>