GET /v2/images with limit doesn't respect sort settings

Bug #1782921 reported by Tom Carrio
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Brin Zhang

Bug Description

If using both "limit" and "sort", the returned subsequent pages are not necessarily in order overall but only within individual pages.

This behavior was exhibited while developing against the gophercloud SDK.

This may be the intended functionality as it is now, but it may be better for pages to consider the sort in regards to all matches when going through pages.

Furthermore, does this behavior mean this is expected of all OpenStack searches? Currently, the limit is set (when None) to the configured API limit. By that, does this mean the following situation would be possible:

With 1000 images returned to match your search, and an API limit of 100 per query, you may have to go through all 10 pages prior to finding the correct match for your search? Since it appears that the exhibited functionality is the sorting is applied to individual pages, it will find 100 matches, sort those, and return that.

I was concerned that may not be the intended functionality, and that if you were searching perhaps the most recent image (on topic with how we found this issue), it should absolutely be the first match in the first page, as well as the last match in the last page would be the oldest image.

Further information with how we came across this and the code involved from skimming through the v2 images code:

- Trace:
- Trace:
- Trace:
- Encountered issue:

Erno Kuvaja (jokke)
Changed in glance:
importance: Undecided → High
Brin Zhang (zhangbailin)
Changed in glance:
assignee: nobody → Brin Zhang (zhangbailin)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.