<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Aug 14, 2015, at 14:22, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 08/14/2015 02:31 PM, David Lyle
wrote:<br>
</div>
<blockquote cite="mid:CAFFhzB7+y6=MTKOJhC0wOj8L2PEOE-hzPeNgAaPxVEVOyes3gw@mail.gmail.com" type="cite">
<div dir="ltr">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.</div>
</blockquote>
<br>
Not possible. Federation is a mapping from a remote service.<br>
<br>
We don't have the data.<br>
<br>
The only place where Keystone is likely to be holding on to users is
for service users.<br>
<br>
<br>
This is not the Keystone team being stubborn. These are technical
and practical limitations based on how OpenStack is being deployed
in the wild.<br>
<br>
<br>
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. <br>
<br>
<br></div></blockquote><div><br></div><div>It also looks to be forward paging only, going back a page requires starting the query over. An error will require starting the query over. LDAP paging is meant to allow gathering of more data than server max not offset based. Order is not guaranteed on any restart, so it is likely to be major inconsistencies in what is on a page instead of minor. </div><br><blockquote type="cite"><div>
<br>
<br>
<br>
<br>
<blockquote cite="mid:CAFFhzB7+y6=MTKOJhC0wOj8L2PEOE-hzPeNgAaPxVEVOyes3gw@mail.gmail.com" type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Not to mention API consistency, which others have already
brought up.<br>
<div><br>
</div>
<div>David<br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 14, 2015 at 9:02 AM, Morgan
Fainberg <span dir="ltr"><<a moz-do-not-send="true" href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>
<br>
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).<br>
<br>
--Morgan<br>
<br>
Sent via mobile<br>
<div class="HOEnZb">
<div class="h5"><br>
> On Aug 14, 2015, at 07:39, Jay Pipes <<a moz-do-not-send="true" href="mailto:jaypipes@gmail.com"></a><a class="moz-txt-link-abbreviated" href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>
wrote:<br>
><br>
>> On 08/14/2015 09:14 AM, Morgan Fainberg wrote:<br>
>> As a quick note the api-ref you are linking to
has some gaps/has not<br>
>> been kept in sync with the official api
specifications.<br>
>><br>
>> The official API specification is located at<br>
>> <a moz-do-not-send="true" href="http://specs.openstack.org/openstack/keystone-specs/" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/keystone-specs/</a>
(v2 and v3 sections<br>
>> at the top) and there is a known open bug to
work with the docs team to<br>
>> get this in sync (somehow).<br>
>><br>
>> Unfortunately there are a number of cases
especially with the identity<br>
>> backend where pagination just does not work (or
works completely<br>
>> unreliably) such as utilizing the ldap driver.
Either a cursor must be<br>
>> maintained (problematic in REST) or the results
could be wildly<br>
>> different every single request meaning each
page is not really<br>
>> guaranteed to be the "next page" it could be
the same/show inconsistent<br>
>> results. The second issue is that the
pagination is not a good UX even<br>
>> where it works - the simple question is: if you
can filter the results<br>
>> how many pages deep do you go before refining
the query; think of your<br>
>> use of search engines.<br>
>><br>
>> In light of these issues Keystone has opted for
a filter / limit<br>
>> (config). If the results exceed the limit there
is a truncation that<br>
>> occurs and it is recommended extra filtering be
applied to reduce the<br>
>> total number of results.<br>
>><br>
>> This discussion has gone around a few times,
pagination in keystone is<br>
>> not currently on the roadmap. In addition to
the above doc bug, we<br>
>> should work to better socialize this
filter-over-paginate methodology.<br>
><br>
> 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.<br>
><br>
> Best,<br>
> -jay<br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage
questions)<br>
> Unsubscribe: <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>