Open Stack

On 08/12/2013 09:22 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis) 
wrote:
>
> The main reason I use user lists (i.e. keystone user-list) is to get 
> the list of usernames/IDs for other keystone commands. I do not see 
> the value of showing all of the users in an LDAP server when they are 
> not part of the keystone database (i.e. do not have roles assigned to 
> them). Performing a "keystone user-list" command against the HP 
> Enterprise Directory locks up keystone for about 1 ½ hours in that it 
> will not perform any other commands until it is done.  If it is 
> decided that user lists are necessary, then at a minimum they need to 
> be paged to return control back to keystone for another command.
>

We need a way to tell HP ED to limit the number of rows, and to do 
filtering.

We have a bug for the second part.  I'll open one for the limit.

> Mark
>
> *From:*Adam Young [mailto:ayoung at redhat.com]
> *Sent:* Monday, August 12, 2013 5:27 PM
> *To:* openstack-dev at lists.openstack.org
> *Subject:* Re: [openstack-dev] [keystone] Pagination
>
> On 08/12/2013 05:34 PM, Henry Nash wrote:
>
>     Hi
>
>     I'm working on extending the pagination into the backends.  Right
>     now, we handle the pagination in the v3 controller class....and in
>     fact it is disabled right now and we return the whole list
>     irrespective of whether page/per-page is set in the query string,
>     e.g.:
>
> Pagination is a broken concept. We should not be returning lists so 
> long that we need to paginate. Instead, we should have query limits, 
> and filters to refine the queries.
>
> Some people are doing full user lists against LDAP.  I don't need to 
> tell you how broken that is.  Why do we allow user-list at the Domain 
> (or unscoped level)?
>
> I'd argue that we should drop enumeration of objects in general, and 
> certainly limit the number of results that come back.  Pagination in 
> LDAP requires cursors, and thus continuos connections from Keystone to 
> LDAP...this is not a scalable solution.
>
> Do we really need this?
>
>
>
> def*paginate*(cls, context, refs):
>
> /"""Paginates a list of references by page & per_page query strings."""/
>
> # FIXME(_dolph_): client needs to support pagination first
>
> returnrefs
>
>       page = context[/'query_string'/].get(/'page'/, 1)
>
>       per_page = context[/'query_string'/].get(/'per_page'/, 30)
>
> returnrefs[per_page * (page - 1):per_page * page]
>
> I wonder both for the V3 controller (which still needs to handle 
> pagination for backends that do not support it) and the backends that 
> do....whether we could use wether 'page' is defined in the 
> query-string as an indicator as to whether we should paginate or not? 
>  That way clients who can handle it can ask for it, those that 
> don'twill just get everything.
>
> Henry
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org  <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130812/7ab1f7c8/attachment.html>