I understand the reasoning, but there are use cases for indexing (re: searchlight) and auditing that are completely unsupported in keystone v3. As from keystone, I have no way to exhaustively list who has accounts in my cloud using OpenStack APIs. That seems like a hole that should be filled.
Not to mention API consistency, which others have already brought up. David On Fri, Aug 14, 2015 at 9:02 AM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > For the identity (users and groups) backend as long as we support LDAP > (and as side note federated users never show up in this list anyway) and > with the drive towards pushing all user management out of keystone itself > to ldap or other tools that do it better, I don't see pagination as > something we should be providing. Providing an inconsistent user experience > based on leaking underlying implementation details is something I am very > against. This stance ensures that horizon and other tools like it will not > need to know underlying implementation details to provide a consistent user > experience. Unfortunately here we do need to cater to the lowest common > denominator and filtering/searching/limiting is the clear common mechanism > > With regards to resources (projects, domains, etc) since we no longer > support using LDAP (deprecated with removal in mitaka) I have less strong > feelings towards and wouldn't block efforts to implement if it is not > already available (if not available this is likely a mitaka goal). > > --Morgan > > Sent via mobile > > > On Aug 14, 2015, at 07:39, Jay Pipes <jaypi...@gmail.com> wrote: > > > >> On 08/14/2015 09:14 AM, Morgan Fainberg 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. > > > > I understand all the things you write above about the problems that > Keystone's underlying architecture (driver-based, not always able to do > pagination in the individual drivers). However, it really does mean that > Keystone is the only project in OpenStack that behaves this way. All other > services provide limit/marker paginations, AFAIK, which is efficient and, > while not the same UX as a filtering methodology, is entirely compatible > and complementary to filtering. > > > > Best, > > -jay > > > > > __________________________________________________________________________ > > 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
