Open Stack

The problem with running in memcached is now you have to keep _EVERY_
token in RAM. This is not any cheaper than cleaning out a giant on-disk
table.

Also worth noting is that memcached can produce frustrating results unless
you run it with -M. That is because without -M, your tokens may be removed
well before their expiration and well before memcached fills up if the
slabs that are allocated in the early days of running are filled up.
Also single users that have many tokens will overrun the per-item limit
in memcached with the size of the token ID list.

There's no magic bullet.. just trade-offs that may or may not work well
for your site.

Excerpts from John Dewey's message of 2015-01-27 10:41:33 -0800:
> This is one reason to use the memcached backend. Why replicate these tokens in the first place. 
> 
> On Tuesday, January 27, 2015 at 10:21 AM, Clint Byrum wrote:
> 
> > 
> > Excerpts from Tim Bell's message of 2015-01-25 22:10:10 -0800:
> > > This is often mentioned as one of those items which catches every OpenStack cloud operator at some time. It's not clear to me that there could not be a scheduled job built into the system with a default frequency (configurable, ideally).
> > > 
> > > If we are all configuring this as a cron job, is there a reason that it could not be built into the code ?
> > It has come up before.
> > 
> > The main reason not to build it into the code as it's even better to
> > just _never store tokens_:
> > 
> > https://blueprints.launchpad.net/keystone/+spec/non-persistent-tokens
> > http://git.openstack.org/cgit/openstack/keystone-specs/plain/specs/juno/non-persistent-tokens.rst
> > 
> > or just use certs:
> > 
> > https://blueprints.launchpad.net/keystone/+spec/keystone-tokenless-authz-with-x509-ssl-client-cert
> > 
> > The general thought is that putting lots of things in the database that
> > don't need to be stored anywhere is a bad idea. The need for the cron
> > job is just a symptom of that bug.
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> >