FWIW, we have refactored the revocation tree into a list, this should speed up the revocation process time significantly ( https://review.openstack.org/#/c/311652/)
There is no way to disable revocations, since that would open up a security hole. On Tue, Jun 21, 2016 at 8:55 PM, Sam Morrison <[email protected]> wrote: > > On 22 Jun 2016, at 9:42 AM, Matt Fischer <[email protected]> wrote: > > On Tue, Jun 21, 2016 at 4:21 PM, Sam Morrison <[email protected]> wrote: > >> >> On 22 Jun 2016, at 1:45 AM, Matt Fischer <[email protected]> wrote: >> >> I don't have a solution for you, but I will concur that adding >> revocations kills performance especially as that tree grows. I'm curious >> what you guys are doing revocations on, anything other than logging out of >> Horizon? >> >> >> Is there a way to disable revocations? >> >> Sam >> > > > I don't think so. There is no no-op driver for it that I can see. I've not > tried it but maybe setting the expiration_buffer to a negative value would > cause them to not be retained? > > They expire at the rate your tokens expire (plus a buffer of 30 min by > default) and under typical operation are not generated very often, so > usually when you have say 10-20ish in the tree, its not too bad. It gets > way worse when you have say 1000 of them. However, in our cloud anyway we > just don't generate many. The only things that generate them are Horizon > log outs and test suites that add and delete users and groups. If I knew we > were generating anymore I'd probably setup an icinga alarm for them. When > the table gets large after multiple test runs or we want to do perf tests > we end up truncating the table in the DB. However that clearly is not a > best security practice. > > > > How token TTLs are very low so I’d be willing to remove revocation. The > bulk of data going though our load balancers on API requests if you take > glance images out is requests to the revocation url. > > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
