Open Stack

On 14 Jun 2017, at 9:03, Ivan Kolodyazhny wrote:

> 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.

The problem with "page number" is that it completely breaks down for large sets. If I've got a few million items in a result set, finding the current page number and the total number of pages becomes very expensive server-side. Using the marker pattern allows for walking over the set and returning results without needing to know the total set at the time of creating the response.

Unfortunately, for the marker to work effectively, the result set needs to have a defined order, and this can end up pushing a lot of the work to the client[1] to provide nice sorting, searching, and pagination.

In an ideal world, I'd love to see a service that keeps track of the different "things" that are managed. Want to know all the server images created before Tuesday? Ask the tracker service. Want to know all the cat pictures smaller than 1MB and marked as having a blue background? Ask the tracker service. etc.

What is this tracker service? elastic? glance? glare? searchlight? something else? I don't know.

[1] In general, pushing work to the client is a fantastic idea, but it does come with a "cost", namely developer mental overhead.


--John



>
> 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/


> __________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170614/769784ef/attachment.sig>