Description of problem: Revokd token list is required to maintain that an apparently valid token is actually revoked. However, memcached is ephemeral, and is the backing store for both the tokens and the revoked token list. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Create a bunch of tokens 2. Revoke the tokens 3. Fetch the revocation list 4. Restart memcached 5. Revocation list will be empty. Actual results: Revocation list will be empty. Expected results: Revocation list should show tokens from step 1 Additional info: Memcached is ephemeral. Token revocation list needs a persistent store. SQL does not have this problem. Using something like Cassandra as a KVS will work. ALso potentila is to split revocation list from token list and have them in separate back ends, and then manage them separately.
Upstream issued OSSN, I'll close->upstream if I don't hear what the actual suggestion to do in Fedora openstack-keystone RPM.
This has been the case for a long while. The best practice to date has been to use a Token driver that does not store in volatile storage. For RH OSP 4 this meant SQL. For 5, it might make sense to test the viability of one of the KVS backends like Reddis or MongoDB. There is also an option to use a persisted memcached.