[openstack-dev] [nova] [api] Nova currently handles list with limit=0 quite different for different objects.
Alex Xu
hejie.xu at intel.com
Wed Sep 23 04:56:40 UTC 2015
Hi, Zhengyu,
We discussed this in yesterday Nova API meeting. We think it should get consistent in API-WG.
And there already have patch for pagination guideline https://review.openstack.org/190743 <https://review.openstack.org/190743> , and there also have some discussion on limits.
So we are better waiting the guideline get consistent before fix it.
Thanks
Alex
> On Sep 23, 2015, at 9:18 AM, Zhenyu Zheng <zhengzhenyulixi at gmail.com> wrote:
>
> Any thoughts on this?
>
> On Mon, Sep 14, 2015 at 11:53 AM, Zhenyu Zheng <zhengzhenyulixi at gmail.com <mailto:zhengzhenyulixi at gmail.com>> wrote:
> Hi, Thanks for your reply, after check again and I agree with you. I think we should come up with a conclusion about how we should treat this limit=0 across nova. And that's also why I sent out this mail. I will register this topic in the API meeting open discussion section, my be a BP in M to fix this.
>
> BR,
>
> Zheng
>
> On Sat, Sep 12, 2015 at 12:07 AM, Kevin L. Mitchell <kevin.mitchell at rackspace.com <mailto:kevin.mitchell at rackspace.com>> wrote:
> On Fri, 2015-09-11 at 15:41 +0800, Zhenyu Zheng wrote:
> > Hi, I found out that nova currently handles list with limit=0 quite
> > different for different objects.
> >
> > Especially when list servers:
> >
> > According to the code:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/common.py#n206 <http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/common.py#n206>
> >
> > when limit = 0, it should apply as max_limit, but currently, in:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n1930 <http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n1930>
> >
> > we directly return [], this is quite different with comment in the api
> > code.
> >
> >
> > I checked other objects:
> >
> > when list security groups and server groups, it will return as no
> > limit has been set. And for flavors it returns []. I will continue to
> > try out other APIs if needed.
> >
> > I think maybe we should make a rule for all objects, at least fix the
> > servers to make it same in api and db code.
> >
> > I have reported a bug in launchpad:
> >
> > https://bugs.launchpad.net/nova/+bug/1494617 <https://bugs.launchpad.net/nova/+bug/1494617>
> >
> >
> > Any suggestions?
>
> After seeing the test failures that showed up on your proposed fix, I'm
> thinking that the proposed change reads like an API change, requiring a
> microversion bump. That said, I approve of increased consistency across
> the API, and perhaps the behavior on limit=0 is something the API group
> needs to discuss a guideline for?
> --
> Kevin L. Mitchell <kevin.mitchell at rackspace.com <mailto:kevin.mitchell at rackspace.com>>
> Rackspace
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150923/5a4d985c/attachment.html>
More information about the OpenStack-dev
mailing list