Re: [openstack-dev] [keystone] Flush expired tokens automatically ?
Thanks Adam, Thierry! Dani On Tue, Jan 27, 2015 at 1:43 PM, Adam Young ayo...@redhat.com wrote: Short term answers: The amount of infrastructure we would have to build to replicate CRON is not worth it. Figuring out a CRON strategy for nontrivial deployment is part of a larger data management scheme. Long term answers: Tokens should not be persisted. We have been working toward ephemeral tokens for a long time, but the vision of how to get there is not uniformly shared among the team. We spent a lot of time arguing about AE tokens, which looked promising, but do not support federation. Where we are headed is a split of the data in the token into an ephemeral portion and a persisted portion. The persisted portion would be reused, and would represent the delegation of authority. The epehmeral portion will represent the time aspects of the token: when issued, when expired, etc. The ephemeral portion would refer to the persisted portion. The revocation events code is necessary for PKI tokens, and might be required depending on how we do the ephemeral/persisted split. With AE tokens it would have been necessary, but with a unified delegation mechanism, it would be less so. If anyone feels the need for ephemeral tokens strongly enough to contribute, please let me know. We've put a lot of design into where we are today, and I would encourage you to learn the issues before jumping in to the solutions. I'm more than willing to guide any new development along these lines. __ 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 __ 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
Re: [openstack-dev] [keystone] Flush expired tokens automatically ?
Short term answers: The amount of infrastructure we would have to build to replicate CRON is not worth it. Figuring out a CRON strategy for nontrivial deployment is part of a larger data management scheme. Long term answers: Tokens should not be persisted. We have been working toward ephemeral tokens for a long time, but the vision of how to get there is not uniformly shared among the team. We spent a lot of time arguing about AE tokens, which looked promising, but do not support federation. Where we are headed is a split of the data in the token into an ephemeral portion and a persisted portion. The persisted portion would be reused, and would represent the delegation of authority. The epehmeral portion will represent the time aspects of the token: when issued, when expired, etc. The ephemeral portion would refer to the persisted portion. The revocation events code is necessary for PKI tokens, and might be required depending on how we do the ephemeral/persisted split. With AE tokens it would have been necessary, but with a unified delegation mechanism, it would be less so. If anyone feels the need for ephemeral tokens strongly enough to contribute, please let me know. We've put a lot of design into where we are today, and I would encourage you to learn the issues before jumping in to the solutions. I'm more than willing to guide any new development along these lines. __ 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
Re: [openstack-dev] [keystone] Flush expired tokens automatically ?
Updating subject line to attract keystone devs Daniel Comnea wrote: +100 Dani On Mon, Jan 26, 2015 at 1:10 AM, Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch wrote: 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 ? __ __ Tim __ __ *From:*Mike Smith [mailto:mism...@overstock.com mailto:mism...@overstock.com] *Sent:* 24 January 2015 18:08 *To:* Daniel Comnea *Cc:* OpenStack Development Mailing List (not for usage questions); openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org *Subject:* Re: [Openstack-operators] [openstack-dev][openstack-operators]flush expired tokens and moves deleted instance __ __ It is still mentioned in the Juno installation docs: __ __ By default, the Identity service stores expired tokens in the database indefinitely. The accumulation of expired tokens considerably increases the database size and might degrade service performance, particularly in environments with limited resources. We recommend that you use cron to configure a periodic task that purges expired tokens hourly: # (crontab -l -u keystone 21 | grep -q token_flush) || \ echo '@hourly /usr/bin/keystone-manage token_flush /var/log/keystone/ keystone-tokenflush.log 21' \ /var/spool/cron/keystone __ __ __ __ Mike Smith Principal Engineer, Website Systems Overstock.com http://Overstock.com __ __ On Jan 24, 2015, at 10:03 AM, Daniel Comnea comnea.d...@gmail.com mailto:comnea.d...@gmail.com wrote: __ __ Hi all, I just bumped into Sebastien's blog where he suggested a cron job should run in production to tidy up expired tokens - see blog[1] Could you please remind me if this is still required in IceHouse/ Juno? (i kind of remember i've seen some work being done in this direction but i can't find the emails) Thanks, Dani [1] http://www.sebastien-han.fr/blog/2014/08/18/a-must-have-cron-job-on-your-openstack-cloud/ ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ __ __ __ CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you. __ 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 -- Thierry Carrez (ttx) __ 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
