<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 14, 2015 at 3:55 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 08/14/2015 06:30 PM, Morgan Fainberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Aug 14, 2015, at 15:10, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/14/2015 05:24 PM, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/14/2015 12:43 PM, Michael Krotscheck wrote:<br>
1- Do users want to page through search results?<br>
</blockquote>
Does not matter:  in Federation, the User list is not available.<br>
</blockquote>
<br>
OK, so hobble the entire REST API for the deficiencies/architecture/reality of a single authentication/identity strategy.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2- Do users want to page through filter results? (do they use filter<br>
results?)<br>
</blockquote>
This is the only practical tool available for LDAP.<br>
</blockquote>
<br>
Again, hobble the entire API for the deficiencies and anachronisms of a single identity driver.<br>
</blockquote>
<br>
The SQL driver is at best a toy and should go away.<br>
</blockquote>
<br></span>
And yet it is in deployments all over the world.<br>
<br>
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...<br>
 <br></blockquote><div><br></div><div>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.<br><br></div><div>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. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If anything, we should tell the anachronistic ActiveDirectory and LDAP solutions to "go away" ;)<span><br>
<br>
> 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).<br>
<br></span>
Aren't we talking about "better user management" here?<span><br>
<br></span></blockquote><div><br></div><div>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.<br><br></div><div>With the new Tokenless Auth via x509 (Liberty Target) we now can eliminate service users needing to be in SQL as well. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Again I will reiterate, asking for "every user that could have an assignment" is absurd.<br>
</blockquote>
<br></span>
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.<span><br>
<br></span></blockquote><div><br></div><div>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). <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> 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.<br>
<br></span>
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.<span><br>
</span> <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It wont be a /users API call.<br>
</blockquote>
<br></span>
Why not?<span><br>
<br></span></blockquote><div><br></div><div>See Above comment. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3- If they want to page, do they want to be able to go back a page<br>
and/or know their current page?<br>
4- How much do users care about small data inconsistencies (i.e.<br>
ordering of record sets changing from page-to-page).<br>
</blockquote>
<br>
So, yeah, we could support paging for SQL.<br>
</blockquote>
<br>
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...).<br>
</blockquote>
<br>
I really do not want implementation details to be the cause of a massive UX change.<br>
</blockquote>
<br></span>
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.<span><br>
<br>
> 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.<br>
<br></span>
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...<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br></div><br></div><div class="gmail_quote">--Morgan<br></div></div></div>