[ https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289240#comment-15289240 ]
Alexander Rukletsov commented on MESOS-5155: -------------------------------------------- {noformat} Commit: a28917f188183a4be1c974fc61ef20797cf255af [a28917f] Author: Zhitao Li <zhitaoli...@gmail.com> Date: 18 May 2016 16:17:11 CEST Committer: Alexander Rukletsov <al...@apache.org> Commit Date: 18 May 2016 18:21:40 CEST Used UPDATE_QUOTA_WITH_ROLE for both quota set and remove. To consolidate authorization actions for quota, we introduce a new authorization action `UPDATE_QUOTA_WITH_ROLE` and corresponding ACL. They new action and ACL should be used instead of now deprecated `SET_QUOTA_WITH_ROLE` and `DESTROY_QUOTA_WITH_PRINCIPAL`. Until the end of the deprecation cycle, we will be using both combinations by querying the authorizer twice. Review: https://reviews.apache.org/r/47399/ {noformat} > Consolidate authorization actions for quota. > -------------------------------------------- > > Key: MESOS-5155 > URL: https://issues.apache.org/jira/browse/MESOS-5155 > Project: Mesos > Issue Type: Improvement > Reporter: Alexander Rukletsov > Assignee: Zhitao Li > Labels: mesosphere > > We should have just a single authz action: {{UPDATE_QUOTA_WITH_ROLE}}. It was > a mistake in retrospect to introduce multiple actions. > Actions that are not symmetrical are register/teardown and dynamic > reservations. The way they are implemented in this way is because entities > that do one action differ from entities that do the other. For example, > register framework is issued by a framework, teardown by an operator. What is > a good way to identify a framework? A role it runs in, which may be different > each launch and makes no sense in multi-role frameworks setup or better a > sort of a group id, which is its principal. For dynamic reservations and > persistent volumes, they can be both issued by frameworks and operators, > hence similar reasoning applies. > Now, quota is associated with a role and set only by operators. Do we need to > care about principals that set it? Not that much. -- This message was sent by Atlassian JIRA (v6.3.4#6332)