Open Stack

How about a settings.py switch that would simply allow the deployer to 
entirely disable the list users functionality?

Best,
-jay

On 08/18/2015 12:52 PM, Timur Sufiev wrote:
> IMO, if that's impossible to provide Users pagination/indexing for LDAP
> from technical point of view, we'd better revise the current UI of
> Identity->Users, since most likely production-grade OpenStack
> installations will have LDAP instead of MySQL storage. So I'm for
> gathering more operators/deployers feedback on the pagination (Users
> panel particularly).
>
> I'm inclined to revising existing UI not because I think the Keystone
> community is adamant in doing things the way they're going to, but
> because LDAP storage backend seems to be unavoidable for large OpenStack
> deployments and Horizon shouldn't ignore this fact (what's the point in
> having fancy UI when it's broken for real-world installations?). Of
> course, 'unavoidable' thing is open to discussion.
>
> On Tue, Aug 18, 2015 at 6:30 AM Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
>     On 08/17/2015 09:53 PM, David Lyle wrote:
>>
>>     I think we've conveniently been led off track here. The original
>>     request/subject was regarding pagination of projects in the v3
>>     API. Since this is purely a keystone construct it seems
>>     implausible to me that ldap or the IdP of choice would be limiting
>>     the ability to return a paginated list of all projects. Or groups
>>     or domains or roles for that matter.
>>
>
>     Yeah, SQL can support it.  LDAP assignment can't.  But that is not
>     going to have a long life.
>
>     With Hierarchical projects, we'll probably also have to keep nesting
>     in mind for how we display a project list:  do we always show a flat
>     list, or is a tree closer to what users expect?
>
>     Both are going to work poorly for some deployments and work well for
>     others.
>
>
>>     There is no reason to punt on pagination across the API for one
>>     resource type, which actually would also work with select
>>     backends. Give me something that I can exhaustively list in the
>>     API I can build from.
>>
>>     David
>>
>>     On Aug 17, 2015 10:53 AM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov
>>     <mailto:Kevin.Fox at pnnl.gov>> wrote:
>>
>>         1. yes, but probably only if its a short list. It may be
>>         feasible to show it only if there are 5 or less pages, and
>>         maybe just load all pages of data and paginate it on the
>>         client. If too big, ask the user to refine their search? Or
>>         always paginate to 5, and then the 6th page have a page
>>         requesting further refinement?
>>
>>         2. Not sure what the difference between searching and
>>         filtering is in this context? something like facets? If so,
>>         probably the 5 or less thing would work here too.
>>
>>         3. Yes, but again, probably within a smaller set of pages?
>>
>>         Thanks,
>>         Kevin
>>         ________________________________________
>>         From: Kruithof, Piet [pieter.c.kruithof-jr at hp.com
>>         <mailto:pieter.c.kruithof-jr at hp.com>]
>>         Sent: Sunday, August 16, 2015 9:41 AM
>>         To: openstack-dev at lists.openstack.org
>>         <mailto:openstack-dev at lists.openstack.org>
>>         Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon]
>>         Pagination support for Identity dashboard entities
>>
>>         I like Michael’s response because it moved the thread towards
>>         identifying actual user needs before digging into the
>>         technical feasibility.  IMHO, it would be helpful to have a
>>         few people on the list answer his questions:
>>
>>         1 - Do users want to page through search results?
>>
>>
>>         2 - Do users want to page through filter results? (do they use
>>         filter results?)
>>
>>
>>         3 - If they want to page, do they want to be able to go back a
>>         page and/or know their current page?
>>
>>
>>         I understand that even if we answer “yes” to all three
>>         questions that there could be issues around implementation,
>>         but at least we’ll know a gap exists.
>>
>>
>>         Piet Kruithof
>>         Sr UX Architect, HP Helion Cloud
>>         PTL, OpenStack UX project
>>
>>         "For every complex problem, there is a solution that is
>>         simple, neat and wrong.”
>>
>>         H L Menken
>>
>>
>>         __________________________________________________________________________
>>         OpenStack Development Mailing List (not for usage questions)
>>         Unsubscribe:
>>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe  <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>