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-keystone | Assignee: | 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: | async | Keywords: | 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 18:24:42 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 653629 [details]
httpd error log
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:
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? It seems it got fixed. What about switching this to CLOSED WORKSFORME? |
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