Keystone confuses users when creating a trust when there's a roles name conflict
Bug #1696111 reported by
Michal Dulko
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-
* 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-
[1] https:/
Changed in python-keystoneclient: | |
importance: | Undecided → Low |
Changed in keystone: | |
status: | In Progress → Fix Committed |
Changed in python-keystoneclient: | |
status: | In Progress → Fix Committed |
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.
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/controlle rs.py#L90- L94