On 04/05/2014 01:43 PM, Andrew Mann wrote: > A CLI command is an interesting stopgap, but on a heavily utilized > OpenStack installation with automated tools operating against OpenStack, > this has a high manual maintenance cost. Surely there is some better > default that lies in the middle ground between keeping tokens for ever > and ever and requiring a manual removal of tokens? > > As a reference point, I wasn't even aware this was an issue, until one > of our test deployments of grizzly using a limited IO system started > acting horribly (30 second response times). After tracing the problem > from nova to keystone to mysql, I found a 442,000 row token table with >> 440,000 expired tokens. I went and checked our havana test on a > somewhat beefier system and found > 1M rows. > > This issue is a timebomb for any production OS install. > CRON the CLI job. There is no reason to try and integrate a scheduler into Keystone.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1032633 Title: Keystone's token table grows unconditionally when using SQL backend. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1032633/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
