Cache the token revocation list
The token revocation list is one of the most accessed resources in keystone. Current implementations are too slow.
1. Store the token revocation list in a cache (most likely memcache)
2. flush it on each revocation event and recreate
3. Lazy create it the first time it is accessed.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Low
- Drafter:
- Adam Young
- Direction:
- Approved
- Assignee:
- Morgan Fainberg
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
-
Slow progress
- Milestone target:
- None
- Started by
- Morgan Fainberg
- Completed by
- Morgan Fainberg
Related branches
Related bugs
Sprints
Whiteboard
why not just cache it in memory as a first-pass?
That will work for eventlet but not for HTTPD.
morganfainberg:
We could cache in memory (using something similar to the KVS token driver) but I think that it would be more beneficial (long term) to have the revocation lists be a pluggable driver that handles the caching similar to how the token driver is setup. It seems like a natural place to have an option to manage the revocation list in use-case defined options.
I think the general use-case will be in-memory (that references the SQL back end). Or memcache, but I don't see it being beneficial to forcing an "in-memory" cache (in-process) if the environment is using memcache for the tokens, however, I wouldn't want to force the use of memcache.
Gerrit topic: https:/
Addressed by: https:/
New Revocation List Caching/Handling
Addressed by: https:/
Fixing backend Token purging for memcache
