Open Stack

I understand the reasoning, but there are use cases for indexing (re:
searchlight) and auditing that are completely unsupported in keystone v3.
As from keystone, I have no way to exhaustively list who has accounts in my
cloud using OpenStack APIs. That seems like a hole that should be filled.

Not to mention API consistency, which others have already brought up.

David



On Fri, Aug 14, 2015 at 9:02 AM, 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/4fef4150/attachment.html>