Open Stack

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 <sorrison at gmail.com> wrote:

>
> On 22 Jun 2016, at 9:42 AM, Matt Fischer <matt at mattfischer.com> wrote:
>
> On Tue, Jun 21, 2016 at 4:21 PM, Sam Morrison <sorrison at gmail.com> wrote:
>
>>
>> On 22 Jun 2016, at 1:45 AM, Matt Fischer <matt at mattfischer.com> 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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160621/f967005c/attachment.html>