Bug 1022025

Summary:	restarting memcached loses revoked token list
Product:	[Fedora] Fedora	Reporter:	Adam Young <ayoung>
Component:	openstack-keystone	Assignee:	Alan Pevec (Fedora) <apevec>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	19	CC:	apevec, apevec, ayoung, bfilippov, breu, itamar, Jan.van.Eldik, jonathansteffan, jose.castro.leon, markmc, p, rbryant
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-30 15:57:28 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:

Description Adam Young 2013-10-22 14:03:20 UTC

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.

Comment 1 Alan Pevec 2013-11-26 19:39:56 UTC

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 17:06:38 UTC

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.