<div dir="ltr">I'm having some issues with keystone revocation events. The bottom line is that due to the way keystone handles the clean-up of these events[1], having more than a few leads to:<div><br></div><div> - bad performance, up to 2x slower token validation with about 600 events based on my perf measurements.</div><div> - database deadlocks, which cause API calls to fail, more likely with more events it seems</div><div><br></div><div>I am seeing this behavior in code from trunk on June 11 using Fernet tokens, but the token backend does not seem to make a difference.</div><div><br></div><div>Here's what happens to the db in terms of deadlock:</div><div>2015-07-15 21:25:41.082 31800 TRACE keystone.common.wsgi DBDeadlock: (OperationalError) (1213, 'Deadlock found when trying to get lock; try restarting transaction') 'DELETE FROM revocation_event WHERE revocation_event.revoked_at < %s' (datetime.datetime(2015, 7, 15, 18, 55, 41, 55186),)<br></div><div><br></div><div>When this starts happening, I just go truncate the table, but this is not ideal. If [1] is really true then the design is not great, it sounds like keystone is doing a revocation event clean-up on every token validation call. Reading and deleting/locking from my db cluster is not something I want to do on every validate call.</div><div><br></div><div>So, can I turn of token revocation for now? I didn't see an obvious no-op driver. And in the long-run can this be fixed? I'd rather do almost anything else, including writing a cronjob than what happens now.</div><div><br></div><div>[1] - <a href="http://lists.openstack.org/pipermail/openstack-operators/2015-June/007210.html">http://lists.openstack.org/pipermail/openstack-operators/2015-June/007210.html</a></div></div>