Bug 881105

Summary: The very first token for horizon causes AttributeError: 'NoneType' object has no attribute 'get'.
Product: Red Hat OpenStack Reporter: Jaroslav Henner <jhenner>
Component: openstack-keystoneAssignee: Adam Young <ayoung>
Status: CLOSED WORKSFORME QA Contact: Yaniv Kaul <ykaul>
Severity: low Docs Contact:
Priority: low    
Version: 2.0 (Folsom)CC: jkt
Target Milestone: asyncKeywords: Triaged
Target Release: 2.1   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-13 14:24:42 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
logs
none
httpd error log none

Description Jaroslav Henner 2012-11-28 11:38:49 EST 
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@example.com", "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@example.com", "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 12:16:36 EST 
Created attachment 653629 [details]
httpd error log
Comment 4 Adam Young 2013-03-01 16:07:35 EST 
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 16:35:42 EST 
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 13:41:40 EDT 
It seems it got fixed. What about switching this to CLOSED WORKSFORME?