> On Aug 14, 2015, at 12:19, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > Pagination in ldap requires holding a cursor open. You would have to map the > requests to the same cursor each time. It costs memory and holds a client > connected to the ldap server. In a REST api it is a bad idea. With regard to > searching it can be done, but each query can be a different set of objects > (order is not guaranteed). It isn't straight forward. > > To put is bluntly, we are working to push user management to the tools that > are better at this than keystone. The LDAP servers or AD have far better > tools than the keystone API. And federated users are managed externally as > well. The SQL table to manage users is not a good solution and we are making > strides to eliminate the needs for even service users to exist here. > > The question about roles and grants can be queried and appropriately > paginated/limited/searched (again same statement about resource for > project/domain where if it doesn't exist i wouldn't block it but it is likely > a mitaka target). > That is to say "list all users that could have a role in keystone" is not a good question as it highlights all the aforementioned problems. Asking for a list of active assignments is a reasonable answer as it is tied to a backend that can support what you're asking for (it isnt directly tied to identity, but to the assignment/role backend) > --Morgan > > Sent via mobile > >> On Aug 14, 2015, at 09:42, Fox, Kevin M <kevin....@pnnl.gov> wrote: >> >> Surely ldap supports some form of pagination/searching natively. If any >> storage system of users needs to scale up to large numbers of users, its >> ldap... >> >> Thanks, >> Kevin >> From: Timur Sufiev [tsuf...@mirantis.com] >> Sent: Friday, August 14, 2015 9:20 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for >> Identity dashboard entities >> >> Morgan, >> >> Your reasoning is perfectly fine from the Keystone point of view. Yet I >> believe this approach is harmful for both Horizon and the whole OpenStack >> ecosystem. >> >> It is harmful for the ecosystem, because it breaks API uniformity in one of >> the few areas where this uniformity could be achieved. Imagine if Nova or >> Cinder start saying the same thing: "we have too much drivers/backends to >> provide the uniform interface for all of them, let's delegate the choice of >> handling them differently to our consumers". It'll propagate the knowledge >> of different backends throughout the stack and it's obviously not good. >> >> Not having pagination on Identity->Users page means that even with filtering >> being fully supported there will be problems. At least the first time the >> Users page with all the Users piped from production-grade LDAP through >> Keystone is shown in Horizon, it takes a lot time to render them all (before >> an unhappy admin had any chance to narrow the list), which eventually may >> result in connection being dropped by some HA balancer. We did these kinds >> of tests, the results weren't reassuring. Well, I might miss some of new >> Horizon angularization steps, so please regard this paragraph as my personal >> opinion - I don't think Horizon could be lighting fast on its own (i.e. >> without additional services) with a lot of data without pagination. >> >>> On Fri, Aug 14, 2015 at 6:03 PM 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
__________________________________________________________________________ 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
