Open Stack

I don't have a horse in the "What should keystone support" race. I do,
however, need to point out that any UX argument made about how a UI should
work should, at this point, ask the OpenStack UX program for help! Thus
I've changed the topic of this email to make sure Piet and the UX teams get
a chance to respond.

It feels like we have four UX assumptions, which I feel should be converted
into questions:
1- Do users want to page through search results?
2- Do users want to page through filter results? (do they use filter
results?)
3- If they want to page, do they want to be able to go back a page and/or
know their current page?
4- How much do users care about small data inconsistencies (i.e. ordering
of record sets changing from page-to-page).

Also, from personal experience, it is impossible to make a "search"
implementation that users, especially enterprise users, trust. I personally
blame Sharepoint for that.

Michael

On Fri, Aug 14, 2015 at 6:17 AM Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> As a quick note the api-ref you are linking to has some gaps/has not been
> kept in sync with the official api specifications.
>
> The official API specification is located at
> http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3 sections
> at the top) and there is a known open bug to work with the docs team to get
> this in sync (somehow).
>
> Unfortunately there are a number of cases especially with the identity
> backend where pagination just does not work (or works completely
> unreliably) such as utilizing the ldap driver. Either a cursor must be
> maintained (problematic in REST) or the results could be wildly different
> every single request meaning each page is not really guaranteed to be the
> "next page" it could be the same/show inconsistent results. The second
> issue is that the pagination is not a good UX even where it works - the
> simple question is: if you can filter the results how many pages deep do
> you go before refining the query; think of your use of search engines.
>
> In light of these issues Keystone has opted for a filter / limit (config).
> If the results exceed the limit there is a truncation that occurs and it is
> recommended extra filtering be applied to reduce the total number of
> results.
>
> This discussion has gone around a few times, pagination in keystone is not
> currently on the roadmap. In addition to the above doc bug, we should work
> to better socialize this filter-over-paginate methodology.
>
> --Morgan
>
> Sent via mobile
>
> On Aug 14, 2015, at 05:46, Timur Sufiev <tsufiev at mirantis.com> wrote:
>
> Hello, Keystone folks!
>
> I've just discovered an unfortunate fact that Horizon pagination for
> Tenants/Projects list that worked with Keystone v2 doesn't work with
> Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
> parameters [1] that Horizon is relying upon. Meanwhile having looked
> through [2] and [3] I'm a bit confused: while Keystone v3 API states it
> supports [2] pagination for every kind of entities (by using 'page' and
> 'per_page' parameters), the related blueprint [3] is not yet approved,
> meaning that most likely the API implementation did not make it into
> existing Keystone codebase. So I wonder whether there are some plans to
> implement pagination for Keystone API calls that list its entities?
>
> P.S. I'm aware of SearchLight project that tries to help Horizon with
> other OpenStack APIs (part of its mission), what I'm trying to understand
> here is are we going to have some fallback pagination mechanism for
> Horizon's Identity in a short-term/mid-term perspective.
>
> [1] http://developer.openstack.org/api-ref-identity-admin-v2.html
> [2] http://developer.openstack.org/api-ref-identity-v3.html
> [3] https://blueprints.launchpad.net/keystone/+spec/pagination
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/2c9cbfd0/attachment.html>