<div dir="ltr">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.<div><br></div><div>It feels like we have four UX assumptions, which I feel should be converted into questions:</div><div>1- Do users want to page through search results?</div><div>2- Do users want to page through filter results? (do they use filter results?)</div><div>3- If they want to page, do they want to be able to go back a page and/or know their current page?<br></div><div>4- How much do users care about small data inconsistencies (i.e. ordering of record sets changing from page-to-page).</div><div><div><br></div><div>Also, from personal experience, it is impossible to make a "search" implementation that users, especially enterprise users, trust. I personally blame Sharepoint for that.</div></div><div><br></div><div>Michael</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 14, 2015 at 6:17 AM Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.</div><div><br></div><div>The official API specification is located at <a href="http://specs.openstack.org/openstack/keystone-specs/" target="_blank">http://specs.openstack.org/openstack/keystone-specs/</a> (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). </div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>--Morgan</div><div><br>Sent via mobile</div></div><div dir="auto"><div><br>On Aug 14, 2015, at 05:46, Timur Sufiev <<a href="mailto:tsufiev@mirantis.com" target="_blank">tsufiev@mirantis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hello, Keystone folks!<div><br></div><div>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?<br><div><br></div><div>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.</div><div><br></div><div>[1] <a href="http://developer.openstack.org/api-ref-identity-admin-v2.html" target="_blank">http://developer.openstack.org/api-ref-identity-admin-v2.html</a></div></div><div>[2] <a href="http://developer.openstack.org/api-ref-identity-v3.html" target="_blank">http://developer.openstack.org/api-ref-identity-v3.html</a></div><div>[3] <a href="https://blueprints.launchpad.net/keystone/+spec/pagination" target="_blank">https://blueprints.launchpad.net/keystone/+spec/pagination</a></div></div>
</div></blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>