Bug 966431 - Keystone Trusts API fails to list trusts with roles specified
Keystone Trusts API fails to list trusts with roles specified
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
Unspecified Unspecified
high Severity high
: z2
: 4.0
Assigned To: Jamie Lennox
: Rebase, Triaged, ZStream
Depends On: 1065319
  Show dependency treegraph
Reported: 2013-05-23 05:31 EDT by Pavel Sedlák
Modified: 2016-04-26 14:34 EDT (History)
9 users (show)

See Also:
Fixed In Version: openstack-keystone-2013.2.2-1.el6ost
Doc Type: Rebase: Bug Fixes Only
Doc Text:
Previously, listing Trusts would result in a 500 error. This was due to an invalid attempt to append the result with information regarding the roles assigned to the trust. With this update, this information has been removed from the API call, and consequently the 500 error is no longer presented.
Story Points: ---
Clone Of:
Last Closed: 2014-03-04 15:12:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1245590 None None None Never
OpenStack gerrit 69514 None None None Never
Red Hat Product Errata RHBA-2014:0213 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform 4 Bug Fix and Enhancement Advisory 2014-03-04 20:11:55 EST

  None (edit)
Description Pavel Sedlák 2013-05-23 05:31:03 EDT
Discovered with and applies to openstack-keystone-2013.1.1-1.el6ost.

When there are existing Trusts with Roles specified, the list-trusts request fails with 500 Internal Server Error.

When there are Trusts but non of them has the Role(s) specified, or after they were deleted, listing of Trusts works correctly.

1) Create Role/User/Project and add that role to the user on that project
> keystone tenant-create/user-create ...
> keystone role-create --name testRole
> keystone user-role-add --user yourUser --role testRole --tenant yourProject

2) Create Trust with a Role(s) specified with request like this:
> localhost:5000 POST /v3/OS-TRUST/trusts
> {"trust":
>  {"impersonation":false,
>   "project_id":"<your-project-id>",
>   "trustor_user_id":"<your-user-id>",
>   "trustee_user_id":"<other-user-id>",
>   "roles":[{"name":"testRole"}]
>   }}

3) List Trusts
> localhost:5000 GET /v3/OS-TRUST/trusts
which ends with 500 error instead of response with list of Trusts:
> reply: 'HTTP/1.1 500 Internal Server Error\r\n'
> header: Vary: X-Auth-Token
> header: Content-Type: application/json
> header: Content-Length: 148
> header: Date: Wed, 22 May 2013 15:30:33 GMT
> Reply body:
> {'error': {'code': 500,
>            'message': "An unexpected error prevented the server from
>                        fulfilling your request. 'id'",
>            'title': 'Internal Server Error'}}

In the keystone.log there is following backtrace after such request:
> 2013-05-22 17:30:33    ERROR [root] 'id'
> Traceback (most recent call last):
>  File "/usr/lib/python2.6/site-packages/keystone/common/wsgi.py", line 236, in __call__
>    result = method(context, **params)
>  File "/usr/lib/python2.6/site-packages/keystone/common/controller.py", line 104, in wrapper
>    return f(self, context, **kwargs)
>  File "/usr/lib/python2.6/site-packages/keystone/trust/controllers.py", line 181, in list_trusts
>    self._fill_in_roles(context, trust, global_roles)
>  File "/usr/lib/python2.6/site-packages/keystone/trust/controllers.py", line 76, in _fill_in_roles
>    if x['id'] == trust_role['id']]
> KeyError: 'id'
Comment 5 Jamie Lennox 2013-11-22 02:47:16 EST
Discovered this as well today. It is only reproducable when using role_names not the ids.
Comment 8 Adam Young 2014-01-09 23:35:59 EST
Upstream bug was marked as a duplicate.  Fix was commited in

Reviewed: https://review.openstack.org/60301
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=ab0e2c7667a9adc46fece742e1ee8160879b497b
Comment 11 Pavel Sedlák 2014-01-17 10:34:46 EST
Seems that now this bug applies to stable branches, not just master where it was fixed, so maybe it should be backported stable/havana?
Comment 18 Udi 2014-02-20 07:51:23 EST
successfully listed trusts in:
Comment 20 errata-xmlrpc 2014-03-04 15:12:18 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.