>> were not appropriate for real deployment, and our puppet modules were >> not providing better values >> https://bugzilla.redhat.com/show_bug.cgi?id=1064061.
I'd agree that raising the caching timeout is a not a good "production default" choice. I'd also argue that the underlying issue is fixed with https://review.openstack.org/#/c/69884/ In our testing this patch has speed up the revocation retrieval by factor 120. > The default probably is too low, but raising it too high will cause > concern with those who want revoked tokens to take effect immediately > and are willing to scale the backend to get that result. I agree, and changing defaults has a cost as well: Every deployment solution out there has to detect the value change, update their config templates and potentially also migrate the setting from the old to the new default for existing deployments. Being in that situation, it has happened that we were "surprised" by default changes that had undesireable side effects, just because we chose to overwrite a different default elsewhere. I'm totally on board with having "production ready" defaults, but that also includes that they seldomly change and change only for a very good, possibly documented reason. Greetings, Dirk _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev