[openstack-dev] [Openstack-operators] [openstack-operators] [Keystone] flush expired tokens and moves deleted instance

John Dewey john at dewey.ws
Tue Jan 27 18:41:33 UTC 2015


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
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150127/15f28c5b/attachment.html>


More information about the OpenStack-dev mailing list