Open Stack

Hi stackers,



There are several bugs in Horizon [1], [2] and [3] related to pagination.
TBH, these issues are reproducible via CLI too. Unfortunately, all of them
are related to our API’s implementation [4].

Bugs [1] and [2] can’t be fixed in current API’s implementations because we
use ‘marker’ object in them [4]. We can try to implement some hacks on the
Horizon’s side to play with ‘sort order’ param, but even that in some cases
we can fix all bugs because we don’t have necessary params to good paging
implementation.

What does it mean? E.g:

You have 2 volumes and 1 item per page like described at [5]. In this case,
when we remove volume B we can’t open a page with volume A because current
‘marker’ is volume B and regardless to sort order API will return zero
volumes with this marker.

As a double workaround, we can redirect to the first page. But this makes
Horizon UX more terrible when user has a lot of pages of instances,
volumes, etc and want to delete several of them without using filtering
feature.

As an another option, we can do some hacks on the Horizon side, but it
requires to make more API calls what is not a good option in big production
deployments.

As a long-term solution it could be good to change our API’s to have better
paging. E.g. use ‘page number’ param instead of ‘marker’. API could also
return total_page number so Horizon will be able to use these options to
render paged tables well.

In the world of microversions, we can implement such changes without
breaking any existing API users and change API Guidelines with note about
these changes.

I’m glad to get any feedback from Horizon users, API WG and component teams
if community is interested in this big cross-project effort.

[1] https://bugs.launchpad.net/horizon/+bug/1564498
[2] https://bugs.launchpad.net/horizon/+bug/1212174
[3] https://bugs.launchpad.net/horizon/+bug/1274427
[4]
https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst
[5] https://bugs.launchpad.net/horizon/+bug/1564498/comments/5



Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170614/d6356417/attachment.html>