Open Stack

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...

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>