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-requ...@lists.openstack.org?subject:unsubscribe > (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev