pagination for list operations behaves inconsistently

[Sascha Giebner]

Using pagination with Neutron API behaves inconsistently with documented behavior.
Next/previous links are not what they should be.

Observed behavior:
GET call "floatingips?limit=5&page_reverse=False" returns a first page of results that includes a "next" and "previous" link (should only contain a "next" link)

GET call "networks?limit=5&page_reverse=False" returns a first result page that only includes a "previous" link (should only contain a "next" link)

It seems that either the links are generated in a faulty manner or the wrong page is returned (should be 1st page).

We are using version 2.0

Thx and best regards,
Sascha

[hongbin (hongbin034)]

It looks there are two issues have been raised:

1. The first page with "page_reverse=False" should not contain the previous link.
2. The response of "floatingips" and "networks" is inconsistent.

For #1, according to neutron API reference [1], the sample response of the first page does contain the "previous" link. Therefore, the behavior is compliance with document.

For #2, I couldn't reproduce it in my environment. Below are the responses when I tried to paginate "floatingips" and "networks". Both responses contains the "next" link and the behavior looks consistent:

* floatingips: http://paste.openstack.org/show/722814/
* networks: http://paste.openstack.org/show/722815/

[1] https://developer.openstack.org/api-ref/network/v2/#pagination

[hongbin (hongbin034)]

I am going to mark this bug as "incompleted" to indicate that we need further inputs to triage this bug.

[Sascha Giebner (sascha.giebner)]

Hi, you're right about (1), I overlooked that, sorry.

Also I was not aware of our version, my company uses Mitaka release internally so the issue might already be fixed. Could you advise me on how to find the relevant commit? That would be really helpful.

Just in case I'll still provide some more details (for the network case). In all cases described I only refer to the first result page.

We have 16 networks, a call to "networks" returns all 16.
A call to "networks?limit=20" returns 14 results and a "previous" link.
A call to "networks?limit=10" returns 7 results and a "previous" link.
A call to "networks?limit=5" returns 3 results and a "previous" link.

I get the same results when I add "page_reverse=False".

A call to "networks?limit=20&page_reverse=True" returns 14 results and a "next" link.
A call to "networks?limit=10&page_reverse=True" returns 8 results and a "next" link.
A call to "networks?limit=5&page_reverse=True" returns 5 results and both "next" and "previous".

[Andrew Karpow (andyonce)]

Hi, we reproduced the Bug, it happens due to usage of authz policy.json:

https://github.com/openstack/neutron/blob/mitaka-eol/neutron/api/v2/base.py#L275

As you see the pagination_helper is initialised with the database item list instead of the one resulting after applying the policy.json rules.

This breaks the pagination_helper.get_links if the item list is reduced due to policies - also you get fewer results than limit.

Proposed Solution: Move the policy logic to the database abstraction to apply the rules as query filters.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/576910

[Slawek Kaplonski (slaweq)]

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/576910
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.