Open Stack

On 2012?11?11? 02:58, Salvatore Orlando wrote:
> 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.

Thanks! API police main :) You are right. I break them. My bad.

> 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!).
You are right!
>
>
> 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.
I think we can waiting for API 2.1. Is there any plan already here for 
API 2.1 on blueprint or wiki? What's time
API 2.1 will coming? I think I can start follow this. :)
> 2) Allow plugins to declare whether they support or not pagination. If 
> not, return an error code, and document it in the API spec.
But I spent some time to think about this. Maybe this is requirement for 
plugins. So let's make it better.

I'm asking myself:
Do we need a method 'adding custom params of request' for plugin?
Maybe some plugins want to support custom params of request. But they 
can't, because plugin
interface didn't support.

How to implement it?
Each method will have different custom params. And we need explicit 
declare for this.
I wrote an implement as POC patch: https://review.openstack.org/#/c/15875/

This patch add request hook for plugin interface. If plugin want to get 
some custom params, it can
add a hook.

Thanks!
Alex Xu

> 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 
> <mailto: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
>                             <mailto: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/
>             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
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20121112/ad4b9b60/attachment.html>