Bug 881105 - The very first token for horizon causes AttributeError: 'NoneType' object has no attribute 'get'.
Summary: The very first token for horizon causes AttributeError: 'NoneType' object has...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 2.0 (Folsom)
Hardware: x86_64
OS: Linux
low
low
Target Milestone: async
: 2.1
Assignee: Adam Young
QA Contact: Yaniv Kaul
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-28 16:38 UTC by Jaroslav Henner
Modified: 2013-07-04 02:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-13 18:24:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (14.38 KB, application/x-xz)
2012-11-28 16:38 UTC, Jaroslav Henner
no flags Details
httpd error log (5.19 KB, text/x-log)
2012-11-28 17:16 UTC, Jaroslav Henner
no flags Details

Description Jaroslav Henner 2012-11-28 16:38:49 UTC
Created attachment 653611 [details]
logs

Description of problem:
With freshly installed OpenStack (using openstack-demo-install), after first login as admin to dashboard and trying to modify quota for admin tenant, I get two messages (red failure and green success):

-----8<-----8<-----8<-----8<
Error: Failed to modify 1 project members and update project quotas.
×

Success: Modified project "admin".
-----8<-----8<-----8<-----8<

But it fails to update them.

This happens twice in the row (4 errors in total), when trying to update them again. Third time it succeeds without error.


Version-Release number of selected component (if applicable):
openstack-keystone-2012.2-6.el6.noarch
openstack-dashboard-2012.2-6.el6.noarch


How reproducible:
Always

Steps to Reproduce:
1. Install using openstack-demo-install
2. Login to dashboard
3. Try modify quotas for admin project --> Err
4. Try modify quotas for admin project --> Err
5. Try modify quotas for admin project --> Success
  
Actual results:


Expected results:
No problems.


Additional info:
I found that after first login, following several tokens are created, but one is suspicious:

{"user": {"email": "admin", "enabled": true, "id": "eff75a9e445349ee9d3b8f84b6648c6f", "name": "admin", "tenantId": null}, "key": "0677ab807d6d4f3888c99d5ab18a091d", "tenant": null, "metadata": {}}

Concretely the part: '"tenant": null' is strange, because it differs from all the others token in the DB:

{"user": {"email": "admin", "enabled": true, "id": "eff75a9e445349ee9d3b8f84b6648c6f", "name": "admin", "tenantId": null}, "key": "324e308a1f684e0aa9a0f3a804207f99", "tenant": {"enabled": true, "id": "a7a8eb65275f435b917c847d675c89d6", "name": "admin", "description": null}, "metadata": {"roles": ["29eb0b4ae4e648a290d8d180d32179bb", "9b36a271d1bb4d17aedb592733f9e018", "494b158ff51143ff976d9e69acd53913"]}}


Note it is possible to store and restore the state of the DB when experimenting with this bug:
mysqldump -pXXXXX --all-databases > dbdump.sql
mysql -pXXXXX < dbdump.sql

Note that in the attached log, the seemingly problematic token is 05f41bbcf93d467aaafd8dc1f9a1c29b

Comment 3 Jaroslav Henner 2012-11-28 17:16:36 UTC
Created attachment 653629 [details]
httpd error log

Comment 4 Adam Young 2013-03-01 21:07:35 UTC
Relevant part of the error log

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/keystone/common/wsgi.py", line 204, in __call__
    result = method(context, **params)
  File "/usr/lib/python2.6/site-packages/keystone/identity/core.py", line 621, in remove_role_from_user
    self.token_api.revoke_tokens(context, user_id, tenant_id)
  File "/usr/lib/python2.6/site-packages/keystone/token/core.py", line 48, in revoke_tokens
    for token_id in self.list_tokens(context, user_id, tenant_id):
  File "/usr/lib/python2.6/site-packages/keystone/common/manager.py", line 47, in _wrapper
    return f(*args, **kw)
  File "/usr/lib/python2.6/site-packages/keystone/token/backends/sql.py", line 113, in list_tokens
    if token_ref_dict['tenant'].get('id') != tenant_id:

Comment 5 Adam Young 2013-03-01 21:35:42 UTC
It looks like this might have been addressed by:

https://github.com/openstack/keystone/commit/80d63c882c7b847a8b73cf1e2b0f587a25be4d5f


It is a different upstream bug.
https://bugs.launchpad.net/keystone/+bug/1078497

Can you verify that this happens in the latest spin?

Comment 6 Jaroslav Henner 2013-03-13 17:41:40 UTC
It seems it got fixed. What about switching this to CLOSED WORKSFORME?


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