Open Stack

On 08/12/2013 08:33 PM, Jay Pipes wrote:
> On 08/12/2013 08:27 PM, Adam Young wrote:
>> 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?
>
> Yes. It is very painful for operators right now to do any sort of 
> administration of identity information when using the SQL backend. In 
> Horizon, the users admin page takes forever and a day to load hundreds 
> or thousands of user records (same for tenants). The CLI is similarly 
> painful in production environments with thousands of user/tenants.
Not arguing that it is not broken.   I would argue that there is 
something broken with out workflows. Pagination is not the answer. Not 
asking for the entire user list is the answer.
Honestly, if the list is 100K long, you are not going to page through 
it.  You need a better search filter.  Lets limit the number of results 
shown, and figure out how to correctly filter results.

>
> Best,
> -jay
>
>>> 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
>>> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev