Cache the token revocation list

Registered by Adam Young on 2013-05-21

This blueprint has been superseded. See the newer blueprint "Caching layer implementation around driver calls." for updated plans.

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 on 2013-05-23
Completed by
Morgan Fainberg on 2013-08-02

Related branches

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://review.openstack.org/#q,topic:bp/cache-token-revocations,n,z

Addressed by: https://review.openstack.org/30326
    New Revocation List Caching/Handling

Addressed by: https://review.openstack.org/27597
    Fixing backend Token purging for memcache

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.