Hey,
As I see, we decided to go the way of limiting and filtering of the
list. Bugreport https://bugs.launchpad.net/keystone/+bug/1501698 was
opened about this issue. I've coded a chain of patches to fix the bug,
please review: https://review.openstack.org/#/c/234849/
On Friday 14 August 2015
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
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
to large numbers of users, its
ldap...
Thanks,
Kevin
From: Timur Sufiev [tsuf...@mirantis.com]
Sent: Friday, August 14, 2015 9:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for
Identity dashboard
Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for
Identity dashboard entities
Morgan,
Your reasoning is perfectly fine from the Keystone point of view. Yet I
believe this approach is harmful for both Horizon
Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for
Identity dashboard entities
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
(not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Horizon] Pagination support for
Identity dashboard entities
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
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.
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
On Aug 14, 2015, at 14:22, Adam Young ayo...@redhat.com wrote:
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
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
Hello, Keystone folks!
I've just discovered an unfortunate fact that Horizon pagination for
Tenants/Projects list that worked with Keystone v2 doesn't work with
Keysone v3 anymore - its API call simply lacks the 'marker' and 'limit'
parameters [1] that Horizon is relying upon. Meanwhile having
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
13 matches
Mail list logo
