Open Stack

On Fri, Aug 14, 2015 at 3:55 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On 08/14/2015 06:30 PM, Morgan Fainberg wrote:
>
>> On Aug 14, 2015, at 15:10, Jay Pipes <jaypipes at 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...
>
>

The SQL identity backend is not providing comperable capabilities in a real
way. It is providing a very limited store for a user data. It does not
provide password complexity management, it does not allow for lockout based
on failed logins, it does not provide limits on re-use of password, it does
not provide clear user/group lifecycle management. It is not a real
identity store, it is a very limited example implementation.

These are all thing that have been regular requests of Keystone and
provided for free with the most basic LDAP installation (or FreeIPA). I am
inclined to say we should be moving towards LDAP being the identity store
by default instead of continuing to use the SQL store and do the
significant levels of enhancements needed (we have asked at midcycles and
summits and have had no one interested in doing this enhancement work). The
comparison to MySQL is incorrect, MySQL legitimately comparable featureset
to the other options and the SQL data store we are using in openstack lacks
basic identity management capabilities.


> 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?
>
>
And Keystone's APIs are very poor user management. There are tools/systems
out there that do it far better that we can leverage. FreeIPA is one such
example. The Keystone User Management API is unused in many deployments and
will not be considered for defcore because most all deployments use a
read-only mode managed by an external service.

With the new Tokenless Auth via x509 (Liberty Target) we now can eliminate
service users needing to be in SQL as well.


> 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 are asking for it without being explicit about it (or may not be
aware). Asking Keystone to list users is infact list all users the Keystone
service can see assignments or not. What I've been advocating as the
alternative is to use the "query active assignments" API calls (and enhance
those) to show who has access to the OpenStack service. It wont be a /users
call because /users is tied to the identity subsystem that (above) isn't
part of defcore and wont be because of the aforementioned "read-only and
externally managed" system. The exception may be the "search for a user"
API I was alluding to that should be implemented/enhanced for the sake of
finding a specific user (if the user in question doesn't have an active
assignment).


> > 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?
>
>
See Above comment.


> 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.
>
>
I disagree with your assessment (and I think we will have to agree to
disagree) but you are asking for *exactly* an implementation detail to
dictate UX and require consuming projects (or users who are directly
interacting with the API) to either "discover/figure out" or just "know"
that this deployment is different.

The TL;DR of my argument is we should move towards a tool (FreeIPA?) that
is providing real identity management feature sets. Currently those
developing for Keystone are not interested in enhancing the SQL driver (and
we have asked) and being responsible for all the nuances/potential issues
that come with managing these features where we could get it for free by
using something that already does it and has a team dedicated to covering
bugs/enhancing the features. If there is a dedicated stake holder who is
willing to continue support for these enhancements (drive-by not welcome)
and provide the man-power it might be something worth considering. But my
argument against pagination here won't change.

Keystone has been focused on translating the "real" identity stores to
something OpenStack can understand. We simply have limited bandwidth on
what we can accomplish.

--Morgan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/6abde36f/attachment.html>