Open Stack

Morgan,

Your reasoning is perfectly fine from the Keystone point of view. Yet I
believe this approach is harmful for both Horizon and the whole OpenStack
ecosystem.

It is harmful for the ecosystem, because it breaks API uniformity in one of
the few areas where this uniformity could be achieved. Imagine if Nova or
Cinder start saying the same thing: "we have too much drivers/backends to
provide the uniform interface for all of them, let's delegate the choice of
handling them differently to our consumers". It'll propagate the knowledge
of different backends throughout the stack and it's obviously not good.

Not having pagination on Identity->Users page means that even with
filtering being fully supported there will be problems. At least the first
time the Users page with all the Users piped from production-grade LDAP
through Keystone is shown in Horizon, it takes a lot time to render them
all (before an unhappy admin had any chance to narrow the list), which
eventually may result in connection being dropped by some HA balancer. We
did these kinds of tests, the results weren't reassuring. Well, I might
miss some of new Horizon angularization steps, so please regard this
paragraph as my personal opinion - I don't think Horizon could be lighting
fast on its own (i.e. without additional services) with a lot of data
without pagination.

On Fri, Aug 14, 2015 at 6:03 PM Morgan Fainberg <morgan.fainberg at gmail.com>
wrote:

> For the identity (users and groups) backend as long as we support LDAP
> (and as side note federated users never show up in this list anyway) and
> with the drive towards pushing all user management out of keystone itself
> to ldap or other tools that do it better, I don't see pagination as
> something we should be providing. Providing an inconsistent user experience
> based on leaking underlying implementation details is something I am very
> against. This stance ensures that horizon and other tools like it will not
> need to know underlying implementation details to provide a consistent user
> experience. Unfortunately here we do need to cater to the lowest common
> denominator and filtering/searching/limiting is the clear common mechanism
>
> With regards to resources (projects, domains, etc) since we no longer
> support using LDAP (deprecated with removal in mitaka) I have less strong
> feelings towards and wouldn't block efforts to implement if it is not
> already available (if not available this is likely a mitaka goal).
>
> --Morgan
>
> Sent via mobile
>
> > On Aug 14, 2015, at 07:39, Jay Pipes <jaypipes at gmail.com> wrote:
> >
> >> On 08/14/2015 09:14 AM, Morgan Fainberg wrote:
> >> As a quick note the api-ref you are linking to has some gaps/has not
> >> been kept in sync with the official api specifications.
> >>
> >> The official API specification is located at
> >> http://specs.openstack.org/openstack/keystone-specs/ (v2 and v3
> sections
> >> at the top) and there is a known open bug to work with the docs team to
> >> get this in sync (somehow).
> >>
> >> Unfortunately there are a number of cases especially with the identity
> >> backend where pagination just does not work (or works completely
> >> unreliably) such as utilizing the ldap driver. Either a cursor must be
> >> maintained (problematic in REST) or the results could be wildly
> >> different every single request meaning each page is not really
> >> guaranteed to be the "next page" it could be the same/show inconsistent
> >> results. The second issue is that the pagination is not a good UX even
> >> where it works - the simple question is: if you can filter the results
> >> how many pages deep do you go before refining the query; think of your
> >> use of search engines.
> >>
> >> In light of these issues Keystone has opted for a filter / limit
> >> (config). If the results exceed the limit there is a truncation that
> >> occurs and it is recommended extra filtering be applied to reduce the
> >> total number of results.
> >>
> >> This discussion has gone around a few times, pagination in keystone is
> >> not currently on the roadmap. In addition to the above doc bug, we
> >> should work to better socialize this filter-over-paginate methodology.
> >
> > I understand all the things you write above about the problems that
> Keystone's underlying architecture (driver-based, not always able to do
> pagination in the individual drivers). However, it really does mean that
> Keystone is the only project in OpenStack that behaves this way. All other
> services provide limit/marker paginations, AFAIK, which is efficient and,
> while not the same UX as a filtering methodology, is entirely compatible
> and complementary to filtering.
> >
> > Best,
> > -jay
> >
> >
> __________________________________________________________________________
> > 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/b9222e5d/attachment.html>