<div dir="ltr">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). <div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 18, 2015 at 6:30 AM Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <div>On 08/17/2015 09:53 PM, David Lyle
      wrote:<br>
    </div>
    <blockquote type="cite">
      <p dir="ltr">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.</p>
    </blockquote>
    <br></div><div text="#000000" bgcolor="#FFFFFF">
    Yeah, SQL can support it.  LDAP assignment can't.  But that is not
    going to have a long life.<br>
    <br>
    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?<br>
    <br>
    Both are going to work poorly for some deployments and work well for
    others.</div><div text="#000000" bgcolor="#FFFFFF"><br>
    <br>
    <blockquote type="cite">
      <p dir="ltr">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. </p>
    </blockquote>
    <blockquote type="cite">
      <p dir="ltr">David</p>
      <div class="gmail_quote">On Aug 17, 2015 10:53 AM, "Fox, Kevin M"
        <<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>>
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
          <br>
          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.<br>
          <br>
          3. Yes, but again, probably within a smaller set of pages?<br>
          <br>
          Thanks,<br>
          Kevin<br>
          ________________________________________<br>
          From: Kruithof, Piet [<a href="mailto:pieter.c.kruithof-jr@hp.com" target="_blank">pieter.c.kruithof-jr@hp.com</a>]<br>
          Sent: Sunday, August 16, 2015 9:41 AM<br>
          To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
          Subject: Re: [openstack-dev] [UX] [Keystone] [Horizon]
          Pagination support for Identity dashboard entities<br>
          <br>
          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:<br>
          <br>
          1 - Do users want to page through search results?<br>
          <br>
          <br>
          2 - Do users want to page through filter results? (do they use
          filter results?)<br>
          <br>
          <br>
          3 - If they want to page, do they want to be able to go back a
          page and/or know their current page?<br>
          <br>
          <br>
          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.<br>
          <br>
          <br>
          Piet Kruithof<br>
          Sr UX Architect, HP Helion Cloud<br>
          PTL, OpenStack UX project<br>
          <br>
          "For every complex problem, there is a solution that is
          simple, neat and wrong.”<br>
          <br>
          H L Menken<br>
          <br>
          <br>
__________________________________________________________________________<br>
          OpenStack Development Mailing List (not for usage questions)<br>
          Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
          <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
          <br>
__________________________________________________________________________<br>
          OpenStack Development Mailing List (not for usage questions)<br>
          Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
          <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>