Keystone confuses users when creating a trust when there's a roles name conflict

Bug #1696111 reported by Michal Dulko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Low
Kristi Nikolla
python-keystoneclient
Fix Released
Low
Kristi Nikolla
python-openstackclient
Fix Released
Undecided
Unassigned

Bug Description

Due to code [1] Keystone produces a confusing message when:

* We're using python-openstackclient
* We're creating a trust with a role name that exists in more that one domain.

"role %s is not defined" suggests that there isn't a role like that. What actually happens, Keystone cannot decide which role is the user's choice.

python-openstackclient automatically converts role ids to role names when sending a POST request, so specifying roles using an id doesn't help at all.

[1] https://github.com/openstack/keystone/blob/03319d1/keystone/trust/controllers.py#L90-L94

Revision history for this message
Lance Bragstad (lbragstad) wrote :

It sounds like the proper fix to this is to allow for python-openstackclient to pass role ids instead of automatically converting them to names. As you noted, keystone already has the logic to bypass the name-id conversion if id are used originally [0]. Otherwise we might be able to take the opportunity to improve the error message in keystone to say something along the lines of ambiguity instead of Not Found.

[0] https://github.com/openstack/keystone/blob/03319d1/keystone/trust/controllers.py#L90-L94

Changed in keystone:
status: New → Triaged
importance: Undecided → Low
Revision history for this message
Kristi Nikolla (knikolla) wrote :

Also affects python-keystoneclient as it only support names. [0]
Agree that the correct solution is to allow ids also.

0. https://github.com/openstack/python-keystoneclient/blob/71af540c81ecb933d912ef5ecde128afcc0deeeb/keystoneclient/v3/contrib/trusts.py#L41

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to python-keystoneclient (master)

Fix proposed to branch: master
Review: https://review.openstack.org/475010

Changed in python-keystoneclient:
assignee: nobody → Kristi Nikolla (knikolla)
status: New → In Progress
Changed in python-keystoneclient:
importance: Undecided → Low
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-keystoneclient (master)

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

commit ef49844248661671063567f98016e88943955ba0
Author: Kristi Nikolla <email address hidden>
Date: Fri Jun 16 11:30:56 2017 -0400

    Add support for specifying role ids when creating trust

    Change-Id: I38e0ac35946ee6e53128babac3ea759a380572e0
    Partial-Bug: 1696111

Revision history for this message
Lance Bragstad (lbragstad) wrote :

There are three possible patches for this issue:

python-keystoneclient needs to support role ids (merged)
python-openstackclient needs to support role ids (in review)
keystone should emit a better error message (not proposed yet)

The python-openstackclient patch is available for review here - https://review.openstack.org/#/c/475068/

Changed in keystone:
milestone: none → pike-3
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/476451

Changed in keystone:
assignee: nobody → Kristi Nikolla (knikolla)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to python-openstackclient (master)

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

commit da53c2b33457f4f1e93bdda6c0c16172ea36bc78
Author: Kristi Nikolla <email address hidden>
Date: Fri Jun 16 15:33:46 2017 -0400

    When creating a trust, send role_ids instead or role_names

    This changes create a trust to use ids instead of names because of
    the possibility of roles sharing a name. Even if the user
    uniquely identified a role by inputting the id, the request sent
    to the identity service would used the name, therefore the command
    would fail in the case that two roles share a name.

    This does not change how trusts are displayed during trust list or
    trust show, a name will still be shown instead of an id.

    Depends-On: I38e0ac35946ee6e53128babac3ea759a380572e0

    Change-Id: I5bdf89f1e288954a7f5c2704231f270bc7d196f5
    Closes-Bug: 1696111

Changed in python-openstackclient:
status: New → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit 1ec118a85f1e31573813e6b433a35d87f0f5bfb8
Author: Kristi Nikolla <email address hidden>
Date: Thu Jun 22 10:13:30 2017 +0000

    Return 400 when trying to create trust with ambiguous role name

    If a user is trying to create a trust by specifying roles by name
    and the name is used by multiple roles, return a more descriptive
    error message. Prior to this it was returning "role not found".

    Change-Id: Ife437ac15774f546f551e191cd5e6fdde7c67d49
    Partial-Bug: 1696111

Changed in keystone:
status: In Progress → Fix Committed
Changed in python-keystoneclient:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/python-openstackclient 3.12.0

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

Changed in keystone:
status: Fix Committed → Fix Released
Changed in python-keystoneclient:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.