Open Stack

On 08/14/2015 02:31 PM, David Lyle wrote:
> 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 possible.  Federation is a mapping from a remote service.

We don't have the data.

The only place where Keystone is likely to be holding on to users is for 
service users.


This is not the Keystone team being stubborn.  These are technical and 
practical limitations based on how OpenStack is being deployed in the wild.


LDAP does not provide sufficient tools to do pagination in a practical 
manner.  LDAP does not guarantee ordering for query results, and there 
is no limit and offset.  Holding a cursor open is not allowed by 
corporate IT.






>
> 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 <mailto: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
>     <mailto: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://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
> 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/eaa4818c/attachment.html>