<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2012年11月11日 02:58, Salvatore Orlando
wrote:<br>
</div>
<blockquote
cite="mid:CAGR=i3hAQw8foKX07aDo42TBR+bEUe+MVaCfm4-UC9yVRa-Ydg@mail.gmail.com"
type="cite">Hi,
<div><br>
</div>
<div>I've looked at this patch - as apparently my role is the API
police man :)</div>
<div>Kudos to Akihiro for beating me at it!</div>
<div><br>
</div>
<div>Before dwelling into details about bw compability, let me say
that what Alex has proposed is what already happens on all major
openstack projects.</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
</blockquote>
<br>
Thanks! API police main :) You are right. I break them. My bad.<br>
<br>
<blockquote
cite="mid:CAGR=i3hAQw8foKX07aDo42TBR+bEUe+MVaCfm4-UC9yVRa-Ydg@mail.gmail.com"
type="cite">
<div>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!).</div>
</blockquote>
You are right!<br>
<blockquote
cite="mid:CAGR=i3hAQw8foKX07aDo42TBR+bEUe+MVaCfm4-UC9yVRa-Ydg@mail.gmail.com"
type="cite">
<div><br>
</div>
<div><br>
</div>
<div>I still not sure about the best course of action. I see the
following options, and your feedback would be welcome:</div>
<div>1) Don't break the plugin interface and move pagination to
API 2.1. Decide whether support them both.</div>
</blockquote>
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<br>
API 2.1 will coming? I think I can start follow this. :)
<blockquote
cite="mid:CAGR=i3hAQw8foKX07aDo42TBR+bEUe+MVaCfm4-UC9yVRa-Ydg@mail.gmail.com"
type="cite">
<div>2) Allow plugins to declare whether they support or not
pagination. If not, return an error code, and document it in the
API spec.</div>
</blockquote>
But I spent some time to think about this. Maybe this is requirement
for plugins. So let's make it better.<br>
<br>
I'm asking myself:<br>
Do we need a method 'adding custom params of request' for plugin?<br>
Maybe some plugins want to support custom params of request. But
they can't, because plugin<br>
interface didn't support.<br>
<br>
How to implement it?<br>
Each method will have different custom params. And we need
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
explicit declare for this.<br>
I wrote an implement as POC patch:
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://review.openstack.org/#/c/15875/">https://review.openstack.org/#/c/15875/</a><br>
<br>
This patch add request hook for plugin interface. If plugin want to
get some custom params, it can<br>
add a hook. <br>
<br>
Thanks!<br>
Alex Xu<br>
<br>
<blockquote
cite="mid:CAGR=i3hAQw8foKX07aDo42TBR+bEUe+MVaCfm4-UC9yVRa-Ydg@mail.gmail.com"
type="cite">
<div>3) Just like 2, but emulate pagination in the API layer
(which might inefficient).</div>
<div><br>
</div>
<div>Some more comments inline.</div>
<div><br>
<div class="gmail_quote">On 8 November 2012 16:16, Xu He Jie <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:xuhj@linux.vnet.ibm.com" target="_blank">xuhj@linux.vnet.ibm.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2012年11月08日 14:46, Akihiro MOTOKI wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Alex, Quantum folks,<br>
<br>
Thanks for working on pagination support in Quantum.<br>
The design docs is very detail and code looks almost
good.<br>
</blockquote>
</div>
Akihiro, Thank you for the reply!
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
When adding pagination support, we also need to consider<br>
API v2.0 backward compatibility. According to your
proposal<br>
at least the following points will be changed.<br>
- Not all items are returned in one listing operation<br>
(All items are returned in the current v2.0 API)<br>
</blockquote>
<br>
</div>
We have option 'max_limit' in quantum.conf. We can specific
a special value(example: -1) for<br>
disable pagination. And if user didn't add 'limit' params in
the url, all items are returned in one<br>
list operation. So pagination will be a optional feature. If
user want to use it, just add 'limit' params<br>
in url.</blockquote>
<div><br>
</div>
<div>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. </div>
<div>-1 then does not mean "disable" pagination. It should
mean "no limit".</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
- Pagination link is added in the response.<br>
</blockquote>
<br>
</div>
When user didn't specific a limit value, we don't show the
pagination links.</blockquote>
<div><br>
</div>
<div>Agreed.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Should we change v2.0 API to support pagination, or keep
v2.0 API unchanged<br>
and add pagination support in the next version of API
(v2.1)?<br>
</blockquote>
<br>
</div>
In next version, we can specific a default limit value. Then
force limit the maximum of items<br>
are returned in one operation.</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Before reviewing the patch in gerrit, it is better to
clarify this point.<br>
<br>
Any idea?<br>
<br>
Thanks,<br>
Akihiro Motoki<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
Date: Wed, 31 Oct 2012 15:31:39 +0800<br>
From: Xu He Jie <<a
moz-do-not-send="true"
href="mailto:xuhj@linux.vnet.ibm.com"
target="_blank">xuhj@linux.vnet.ibm.com</a>><br>
Subject: [openstack-dev] [Quantum] Support
pagination in api v2.0<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
Hi, forks,<br>
<br>
I am working on the blueprint 'Support pagination in
api v2.0': <a moz-do-not-send="true"
href="https://blueprints.launchpad.net/"
target="_blank">https://blueprints.launchpad.net/</a><br>
quantum/+spec/support-pagination-in-api-v2<br>
<br>
I finished spec document. Now the blueprint turn
'Definition' to 'Discussion' status. I write spec<br>
document in google doc, you can comment in google
doc or reply this mail. I will appreciate for<br>
any comment!<br>
<br>
Happy to join the team!<br>
<br>
Thanks!<br>
Alex Xu<br>
<br>
<br>
</blockquote>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>