On 08/14/2015 06:30 PM, Morgan Fainberg wrote:
On Aug 14, 2015, at 15:10, Jay Pipes <jaypi...@gmail.com> wrote:
On 08/14/2015 05:24 PM, Adam Young wrote:
On 08/14/2015 12:43 PM, Michael Krotscheck wrote:
1- Do users want to page through search results?
Does not matter: in Federation, the User list is not available.
OK, so hobble the entire REST API for the deficiencies/architecture/reality of
a single authentication/identity strategy.
2- Do users want to page through filter results? (do they use filter
results?)
This is the only practical tool available for LDAP.
Again, hobble the entire API for the deficiencies and anachronisms of a single
identity driver.
The SQL driver is at best a toy and should go away.
And yet it is in deployments all over the world.
People said the same about MySQL. It was a toy and should go away. And
yet, here we are, 15 years later, and MySQL is running in some of the
world's biggest and most complex web applications. Asking for something
to go away because you consider it a toy (a toy with better capabilities
than other things, I might add) doesn't just make it so...
If anything, we should tell the anachronistic ActiveDirectory and LDAP
solutions to "go away" ;)
> We are working diligently to provide the best solution for the small
and large deployments and provide features we are regularly asked for
(password lifecycle, complexity, better user management, etc).
Aren't we talking about "better user management" here?
Again I will reiterate, asking for "every user that could have an assignment"
is absurd.
Nobody is asking for that. We are asking for "list me the first page of
users in the system, ordered by their ID (or email, or whatever)". This
is hardly absurd. In fact, it's how all other OpenStack API services
expose pagination functionality. And it is complementary to things like
Searchlight, not anathema to it.
> You should search for specific users if you need for find a user
without an assignment (they can't access keystone or auth or act on
OpenStack anyway). You should look at active assignments and we can
implement pagination for that.
Where are you coming up with this "find a user without an assignment"
use case? I've yet to hear anyone talking about this. The only use case
that has been discussed is the (very common) one that Horizon needs to
display a page of user account information, sorted by some key and
filtered as needed.
It wont be a /users API call.
Why not?
3- If they want to page, do they want to be able to go back a page
and/or know their current page?
4- How much do users care about small data inconsistencies (i.e.
ordering of record sets changing from page-to-page).
So, yeah, we could support paging for SQL.
That would be great. Double bonus if this pagination API followed the examples
of all the other OpenStack API services and didn't invent its own terms (page,
per_page...).
I really do not want implementation details to be the cause of a massive UX
change.
That is precisely the situation that Horizon finds itself in today:
implementation details of Keystone's backend drivers causing Horizon to
need to deal with Keystone like it's a special unicorn.
> Lets avoid doing that yet again in OpenStack. Asking horizon to have
two completely different mechanisms based on what backend is following a
poor design pattern we keep falling into where we expect the user to
figure out/know what is different between deployments.
No, that is not at all what I said. I said that there should be a
discovery mechanism so that **Horizon** can figure out whether it can
use a standard "get me a page of listed results" user experience, or
whether it can ONLY use a filtering strategy for the user experience...
Nobody has asked the end user to figure out what is different between
deployments. We're talking about the dashboard here, and possibly the
python-keystoneclient.
Best,
-jay
That is becoming a repository for service users only. For the use
cases requested, we do not have the ability to implement.
Sure, but what you[1] *do* have the ability to implement is a capabilities
discovery REST API that would allow tools like Horizon to determine if the only
option available for them would be a filtering API, with no pagination
capabilities.
It would be super awesome if Keystone had such a capabilities discovery API.
Best,
-jay
[1] I don't mean *you* personally, Adam :)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
