Bug 966431 - Keystone Trusts API fails to list trusts with roles specified
Summary: Keystone Trusts API fails to list trusts with roles specified
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z2
: 4.0
Assignee: Jamie Lennox
QA Contact: Udi Kalifon
URL:
Whiteboard:
Depends On: 1065319
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-23 09:31 UTC by Pavel Sedlák
Modified: 2016-04-26 18:34 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2014-03-04 20:12:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1245590 0 None None None Never
OpenStack gerrit 69514 0 None None None Never
Red Hat Product Errata RHBA-2014:0213 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform 4 Bug Fix and Enhancement Advisory 2014-03-05 01:11:55 UTC

Description Pavel Sedlák 2013-05-23 09:31:03 UTC
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 07:47:16 UTC
Discovered this as well today. It is only reproducable when using role_names not the ids.

Comment 8 Adam Young 2014-01-10 04:35:59 UTC
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 15:34:46 UTC
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 Kalifon 2014-02-20 12:51:23 UTC
successfully listed trusts in:
openstack-keystone-2013.2.2-1.el6ost.noarch

Comment 20 errata-xmlrpc 2014-03-04 20:12:18 UTC
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.

http://rhn.redhat.com/errata/RHBA-2014-0213.html


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