[ https://issues.apache.org/jira/browse/HBASE-27784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bryan Beaudreault resolved HBASE-27784. --------------------------------------- Fix Version/s: 2.6.0 3.0.0-beta-1 Release Note: Adds a RegionServer config hbase.quota.user.override.key which can be set to the name of a request attribute whose value should be used as the username when evaluating quotas. Resolution: Fixed > support quota user overrides > ---------------------------- > > Key: HBASE-27784 > URL: https://issues.apache.org/jira/browse/HBASE-27784 > Project: HBase > Issue Type: New Feature > Reporter: Bryan Beaudreault > Assignee: Ray Mattingly > Priority: Major > Fix For: 2.6.0, 3.0.0-beta-1 > > > The below is the original idea that started this work, but not what we > actually landed on. See the first comment from [~rmdmattingly] and the > release note for that. > > Old description: > {quote}Currently we provide the ability to define quotas for namespaces, > tables, or users. On multi-tenant clusters, users may be broken down into > groups based on their use-case. For us this comes down to 2 main cases: > # Hadoop jobs – it would be good to be able to limit all hadoop jobs in > aggregate > # Proxy APIs - this is common where upstream callers don't hit hbase > directly, instead they go through one of many proxy api's. For us we have a > custom auth plugin which sets the username to the upstream caller name. But > it would still be useful to be able to limit all usage from some particular > proxy API in aggregate. > I think this could build upon the idea for Connection attributes in > HBASE-27657. Basically when a Connection is established we can set an > attribute (i.e. quotaGrouping=hadoop or quotaGrouping=MyProxyAPI). In > QuotaCache, we can add a {{getQuotaGroupLimiter(String groupName)}} and also > allow someone to define quotas using {{set_quota TYPE => THROTTLE, GROUP => > 'hadoop', LIMIT => '100M/sec'}} > I need to do more investigation into whether we'd want to return a simple > group limiter (more similar to table/namespace handling) or treat it more > like the USER limiters which returns a QuotaState (so you can limit > by-group-by-table). > We need to consider how GROUP quotas interact with USER quotas. If a user has > a quota defined, and that user is also part of a group with a quota defined, > does the request need to honor both quotas? Maybe we provide a GROUP_BYPASS > setting, similar to GLOBAL_BYPASS? > {quote} -- This message was sent by Atlassian Jira (v8.20.10#820010)