[api][horizon][all] Poorly Pagination UX

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[api][horizon][all] Poorly Pagination UX

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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [api][horizon][all] Poorly Pagination UX

John Dickinson


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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [api][horizon][all] Poorly Pagination UX

Jay Pipes
On 06/14/2017 12:25 PM, John Dickinson wrote:
> What is this tracker service? elastic? glance? glare? searchlight? something else? I don't know.

Searchlight (which is just ES under the hood with integration of various
notification queues for indexing automation).

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [api][horizon][all] Poorly Pagination UX

McLellan, Steven-2
This is what we envisaged for searchlight; a single endpoint to retrieve information across multiple services and regions to make it easier for a user of horizon (for instance) to ask those kinds of arbitrary questions about the current state of resources.

It's unfortunate our swift integration stalled a little; being able to run the kinds of searches across swift containers that are possible on your local filesystem still seems quite compelling. 

Steve


-------- Original message --------
From: Jay Pipes <[hidden email]>
Date: 6/14/17 17:53 (GMT+00:00)
To: [hidden email]
Subject: Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

On 06/14/2017 12:25 PM, John Dickinson wrote:
> What is this tracker service? elastic? glance? glare? searchlight? something else? I don't know.

Searchlight (which is just ES under the hood with integration of various
notification queues for indexing automation).

Best,
-jay

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...