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.fainb...@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 <tsuf...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
