Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/12833 )
Change subject: WIP [master] introduced SentryAuthzCache ...................................................................... Patch Set 2: (2 comments) http://gerrit.cloudera.org:8080/#/c/12833/2//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/12833/2//COMMIT_MSG@7 PS2, Line 7: WIP [master] introduced SentryAuthzCache > I'm planning to handle the thundering herd will be in a follow-up patch, si I meant I'm planning to address the thundering herd request pattern in a separate patch. I think that way it's easier to review and reason about. BTW, I don't quite understand continuous emphasis on the DML vs DDL difference every time talking about authz cache. By my understanding it's all the same: just fetching and maitaining entries in the cache. We need to make it robust, and then any scenarios will benefit from that. http://gerrit.cloudera.org:8080/#/c/12833/2/src/kudu/master/sentry_authz_provider.cc File src/kudu/master/sentry_authz_provider.cc: http://gerrit.cloudera.org:8080/#/c/12833/2/src/kudu/master/sentry_authz_provider.cc@125 PS2, Line 125: 30, > I commented on the design doc about this, but maybe consider making the def I responded on your comment on the design doc. I think it's a question about trade-off between minimizing latency for the majority of authz verification operations and faster propagation of updates on authz info from authz providers. If we want to minimize latency for the majority of authz verification ops and make sense of caching of any information from an authz provider (e.g., Sentry), the TTL for an authz cache entry should be a multiple of the authz token's TTL. Maybe 'one order of magnitude' is a good target. So, I think 10 is a good default value here :) In practice a user should expect that changing (e.g., revoking privileges) has some latency before it takes effect in the very end of the chain. For example, if working with long scans, even short authz token's TTL does not mandate aborting all currently running scan operations started on already verified authz tokens, even if those tokens contain privileges which have been just revoked. What do you think? -- To view, visit http://gerrit.cloudera.org:8080/12833 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: Idaefacd50736f1f152dae34e76778e17b2e84cbe Gerrit-Change-Number: 12833 Gerrit-PatchSet: 2 Gerrit-Owner: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Andrew Wong <aw...@cloudera.com> Gerrit-Reviewer: Hao Hao <hao....@cloudera.com> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Tidy Bot (241) Gerrit-Comment-Date: Wed, 27 Mar 2019 17:08:54 +0000 Gerrit-HasComments: Yes
