Bug 1022025 - restarting memcached loses revoked token list
restarting memcached loses revoked token list
Product: Fedora
Classification: Fedora
Component: openstack-keystone (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Alan Pevec
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-22 10:03 EDT by Adam Young
Modified: 2014-06-27 13:06 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-30 11:57:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1182920 None None None Never

  None (edit)
Description Adam Young 2013-10-22 10:03:20 EDT
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:

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.
Comment 1 Alan Pevec 2013-11-26 14:39:56 EST
Upstream issued OSSN, I'll close->upstream if I don't hear what the actual suggestion to do in Fedora openstack-keystone RPM.
Comment 2 Adam Young 2014-06-27 13:06:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.