yahoo-eng-team team mailing list archive

[Tom Carrio <tom@xxxxxxxxx>]

Public bug reported:

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: https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L181-L191
- Trace: https://github.com/openstack/glance/blob/master/glance/gateway.py#L70-L90
- Trace: https://github.com/openstack/glance/blob/master/glance/api/authorization.py#L110-L112
- Encountered issue: https://github.com/hashicorp/packer/pull/6490/files/9b26a0b6d9a6cdd7e64e3dd3bdd8f313a5628a7e#diff-0dee6a8519558384fb129e344c9f4142R103

** Affects: glance
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1782921

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

Status in Glance:
  New

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: https://github.com/openstack/glance/blob/master/glance/api/v2/images.py#L181-L191
  - Trace: https://github.com/openstack/glance/blob/master/glance/gateway.py#L70-L90
  - Trace: https://github.com/openstack/glance/blob/master/glance/api/authorization.py#L110-L112
  - Encountered issue: https://github.com/hashicorp/packer/pull/6490/files/9b26a0b6d9a6cdd7e64e3dd3bdd8f313a5628a7e#diff-0dee6a8519558384fb129e344c9f4142R103

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1782921/+subscriptions