<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Aug 15, 2015, at 10:58, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com">morgan.fainberg@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div><br>On Aug 15, 2015, at 10:15, Michael Krotscheck <<a href="mailto:krotscheck@gmail.com">krotscheck@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 14, 2015 at 2:26 PM Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br></div><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>
Does not matter: in Federation, the User list is not available.<br></blockquote><div><br></div><div>Let's back up here for a sec: A user wants to page a list of data. This is something horizon needs, traditionally relying on keystone, and now keystone has broken backwards compatibility for horizon because of one use case, without taking responsibility for it and providing (with code) a good alternative. Furthermore, you and your team are saying "You should go use a different service that's better at this", which is basically saying "We live in this silo, we don't have to care about other silo's".<br></div><div><br></div><div>You broke backwards compatibility. It's your responsibility to address it.</div><div><br></div></div></div></div></blockquote><div><br></div><div>Please do not construe a major api change as backwards incompatible. This pagination was never supported in v3 properly/at all. </div><div><br></div><div>The v3 api was never claimed to be backwards compatible; this is a major api version. I am offering a different API that gets the information you need and saying that the request for pagination of every single possible user (the API that people use in v2) is not what we want to maintain in v3 because we are working to remove the need for the badly implemented (and not frequently used) store for user data. </div><div><br></div><div>V2 will not stop it's support (except that it is frozen and will be deprecated in the near future). And v2 will pretty much just fail at pagination with ldap, but this is a long running behavior. </div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div>The other argument I'm hearing here is that keystone is responsible for authentication and authorization, but not user management. I actually agree with this, but nobody's started a user management service and/or its delegation plugins, so now we have a rather large hole in horizon's features, late in a release cycle, and nobody has the resources to address it. What do you propose to do about it?</div><div><br></div></div></div></div></blockquote><div><br></div>As we move towards tools like FreeIPA Or something similar, we will be addressing the gap. <div><br></div><div>I also assert horizon should not be managing users in the same way Keystone should not be managing users. Horizon should show what users have access to openstack (and this *can* be paginated) and allow for searching for a user that is visible to keystone but does not have access to openstack so that they can be grants access. <div><br></div><div>The user management service would be FreeIPA in my previous example (or AD in the environments that deploy it, etc). </div><div><br></div><div>So to distill out what we can do (and what is viable without having wilding different workflows based upon implementation details) and solve the immediate ask for pagination is:</div><div><br></div><div>1: you do not get to list every user visible to keystone via v3. This is where the problems lie.</div><div><br></div><div>2: you can search for users that are visible but do not have an active assignment (this may need some work - and is a reasonable ask). </div><div><br></div><div>2a: if the list of users is small the filter/search could return all users</div><div><br></div><div>3: you can list users with an active assignment (using the assignment apis) and this *can* be paginated (if it does not already support pagination)</div><div><br></div><div>4: (future view) leverage an already existing open source solution for user management such as FreeIPA and remove/deprecate the sql-based data store that is missing basic user management features</div><div><br></div><div>Alternative to 4: find stake holders who want to take on the risk and effort of maintaining and supporting a full fledged identity provider and implement it in the SQL driver. </div></div></div></blockquote><div><br></div>Let me add that the above list does not differ from what I have already said in this thread previously. I have just broken it out explicitly so it is easier to see. <div><br></div><div>I am trying to offer an alternative that meets the ask of the other teams without just saying "no" and shooting the ask down. We have some legitimate reasons for the choices that we have made and are working towards a solution that meets the needs of the community of developers and well as the real operational asks we consistently get from operators/deployers. </div></body></html>