Open Stack

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.

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
        return refs

        page = context['query_string'].get('page', 1)
        per_page = context['query_string'].get('per_page', 30)
        return refs[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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130813/19958126/attachment.html>