On Fri, Aug 14, 2015 at 3:55 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> 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... > > 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
__________________________________________________________________________ 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
