Output from "role assignment list" is not useful

[Julian Edwards]

It's showing the internal IDs of all the objects, which is really unhelpful. It would be much nicer if it showed the actual names of users, groups, projects and domains.

Example:

$ openstack role assignment list
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
| Role | User | Group | Project | Domain |
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+
| 83e948848b7842c9a15e01cfd9db6e1e | 0fa9633d884a42448bbd386778ca6b87 | | 4404002027374bfe878501259b02a5d5 | |
| 83e948848b7842c9a15e01cfd9db6e1e | 0fa9633d884a42448bbd386778ca6b87 | | 5568fe0e2ca74a5aae35b01f035cdee8 | |
| f25338bd4a1f4d74927375507d555fa5 | 339e327397d4437d8d1123d63098de76 | | 67e30450f1c44010960aa7e1a457f9b3 | |
| ecea53c035034e93912428789e8272f6 | 35a3b6d9cb324661b5f144fd60a62964 | | 9b5b2ef803514898b4a3a90ef09dcf66 | |
| 83e948848b7842c9a15e01cfd9db6e1e | 4644b913eb77414db8f344d37e3da2c2 | | 9b5b2ef803514898b4a3a90ef09dcf66 | |
| ecea53c035034e93912428789e8272f6 | 50e99a8a5d6c40b2bd973fe55f2cb38b | | 9b5b2ef803514898b4a3a90ef09dcf66 | |
| f1f56af00ee942a5b24d73dbfe2364cb | 54b9ac936fd04293981b828580a9a3e1 | | 4404002027374bfe878501259b02a5d5 | |
| f25338bd4a1f4d74927375507d555fa5 | 54b9ac936fd04293981b828580a9a3e1 | | 4404002027374bfe878501259b02a5d5 | |
| f25338bd4a1f4d74927375507d555fa5 | 54b9ac936fd04293981b828580a9a3e1 | | c02e1e2d94584805a7445b6d31cab364 | |
| f25338bd4a1f4d74927375507d555fa5 | | 96a35e9d12544ee8aa3cfbf05f2fb649 | 4404002027374bfe878501259b02a5d5 | |
| f25338bd4a1f4d74927375507d555fa5 | 0fa9633d884a42448bbd386778ca6b87 | | | 88fc45635a134ef084866fe0fa94e7f3 |
+----------------------------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+

[Steve Martinelli (stevemar)]

so, the only issue I can think of with this is how we can show the user's domain, group's domain and project's domain. since showing just the name wouldn't be enough, because there may be duplicates.

user | group | project | domain
----------------------------------------------------------------------------------------
steve@d1 | | project@d1 |
steve@d2 | | project@d2 |

right now we don't have a set way of displaying this sort of information.

additionally, we would have to call GET /users/user_id and GET /project/project_id for each result, to get the name and owning domain. that would be very costly.

just my initial thoughts for now, maybe i'll think of a better solution later, but i agree that IDs are not really helpful.

[Julian Edwards (julian-edwards)]

On Thu, 30 Jul 2015 04:14:41 you wrote:
> additionally, we would have to call GET /users/user_id and GET
> /project/project_id for each result, to get the name and owning
domain.
> that would be very costly.
>
> just my initial thoughts for now, maybe i'll think of a better
solution
> later, but i agree that IDs are not really helpful.

I think the server side itself should do a better job here rather than
the client doing the work. This probably means adding an API call.

[Steve Martinelli (stevemar)]

Yeah, part of me wonders why we have this API at all. I wonder who is using it.

[Julian Edwards (julian-edwards)]

Since it's returning internal IDs, I'm betting very few :)

[Lin Hua Cheng (lin-hua-cheng)]

display the role name: https://review.openstack.org/#/c/208108/

[Steve Martinelli (stevemar)]

i'd prefer to fix this on the server side, adding more fields on the server side would be much faster, and save the client from doing a bunch of look ups

[Henry Nash (henry-nash)]

I agree with Steve, maybe he addition of a "/detail" option to the API (or something similar) to ask the server to expand each of the objects into their full entity. It will still be a costly API, but hopefully we could make some savings by doing it server side.

[Julian Edwards (julian-edwards)]

On Thu, 8 Oct 2015 00:20:13 you wrote:
> I agree with Steve, maybe he addition of a "/detail" option to the API
> (or something similar) to ask the server to expand each of the objects
> into their full entity. It will still be a costly API, but hopefully we
> could make some savings by doing it server side.

It shouldn't be any more than an extra DB join or two, I would hope.

[Lin Hua Cheng (lin-hua-cheng)]

@Steve: this API is used in horizon, for the project/domain role assignment panel.

The way it works right now is not pretty:
1. Fetch All Role Assignment for a Project or Domain
2. Fetch All Roles
3. Fetch All Users

Map the Role Assignment to #2 and #3 to render the user and role name.

There is some work ongoing to make Domain Admin and Project Admin use case work in Horizon, in testing the use case for HMT where Project Admin should be able to manage users of it subproject, they hit an issue with the call for #3 (Fetch All Users), because Project Admin doesn't have access to see all Users.

[Steve Martinelli (stevemar)]

@Lin, thanks for mentioning that. This further drives home the point that this API needs to be revisited.

I am also hoping that my listing these role assignments with Group information (something you are missing in Horizon), we can finally close the door on listing LDAP users in horizon (our feedback shows that folks are more interested in seeing what they've given LDAP users in OpenStack, instead of the LDAP users themselves).

[Lin Hua Cheng (lin-hua-cheng)]

@Steve: Actually, we have it. I've implemented the Domain/Project group role assignment as well for Horizon, I think it was around 1.5 years ago. :)

Hit me up if you have questions around the features in Horizon.

[Lin Hua Cheng (lin-hua-cheng)]

superceded by this BP: https://github.com/openstack/keystone-specs/blob/master/specs/mitaka/list-assignment-names.rst

We're going to provide an option to return the object names as well.

[Steve Martinelli (stevemar)]

being addressed by https://review.openstack.org/#/c/249958/

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/254456

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lin Hua Cheng (<email address hidden>) on branch: master
Review: https://review.openstack.org/208108
Reason: superceded by https://review.openstack.org/#/c/255363/1

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/249958
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=dc212cd4d2fa5fe0034f21bfd2a839283749b835
Submitter: Jenkins
Branch: master

commit dc212cd4d2fa5fe0034f21bfd2a839283749b835
Author: Tom Cocozzello <email address hidden>
Date: Wed Nov 25 10:25:28 2015 -0600

    List assignments with names

    When a client calls list assignment API what is returned is the
    role id, user id or group id, and project id or domain id. Most users
    then call the api again for each of these entities to get their names,
    creating many api calls between the client and server. This can
    be reduced by having the server do all the work instead.

    This commit adds the functionality to include the user, role, group,
    project, and domain names with the response if the parameter
    'include_names' is set to True.

    Change-Id: I0a1cc986b8a35aeafe567e5e7fee6eeb848ae113
    Closes-Bug: #1479569
    Implements: blueprint list-assignment-with-names

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/255392
Committed: https://git.openstack.org/cgit/openstack/python-keystoneclient/commit/?id=32ec1722c6fe5b5074070718705ba31ce79b0422
Submitter: Jenkins
Branch: master

commit 32ec1722c6fe5b5074070718705ba31ce79b0422
Author: Tom Cocozzello <email address hidden>
Date: Wed Dec 9 10:38:14 2015 -0600

    Adds an option to include names in role assignment lists

    Allow the client to take advantage of the include_names with
    list role assignments.

    Change-Id: I4aa77c08660a0cbd021502155938a46121ca76ef
    Depends-On: I0a1cc986b8a35aeafe567e5e7fee6eeb848ae113
    Closes-Bug: #1479569
    Implements: blueprint list-assignment-with-names

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/python-keystoneclient 2.2.0 release.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/255363
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=3a48989eb02187f384cfbf7bb7cd55502741fc68
Submitter: Jenkins
Branch: master

commit 3a48989eb02187f384cfbf7bb7cd55502741fc68
Author: Tom Cocozzello <email address hidden>
Date: Wed Dec 9 10:08:16 2015 -0600

    Return names in list role assignments

    Utilize the new include names functionality added to
    list role assignments (GET /role_assignments?include_names=True).
    Which will return the names of the entities instead of their
    IDs.

    Change-Id: I6dc03baf61ef9354a8a259a9f17ff47ce1665ce7
    Depends-On: I4aa77c08660a0cbd021502155938a46121ca76ef
    Closes-Bug: #1479569
    Implements: blueprint list-assignment-with-names

[OpenStack Infra (hudson-openstack)]

Change abandoned by Steve Martinelli (<email address hidden>) on branch: master
Review: https://review.openstack.org/254456
Reason: patch clean up, failed tests and no movement in many months, abandoning

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 9.0.0.0b3 development milestone.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/python-openstackclient 2.2.0 release.