Open Stack

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:

 - bad performance, up to 2x slower token validation with about 600 events
based on my perf measurements.
 - database deadlocks, which cause API calls to fail, more likely with more
events it seems

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.

Here's what happens to the db in terms of deadlock:
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),)

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.

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.

[1] -
http://lists.openstack.org/pipermail/openstack-operators/2015-June/007210.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150715/bc2f63fd/attachment.html>