[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15240286#comment-15240286
]
Zhitao Li commented on MESOS-5155:
----------------------------------
I'll start a patch for this. To be clear,
1. Introducing new Action enum {{UPDATE_QUOTA_WITH_ROLE}} in authorizer.proto;
2. Introducing new message {{UpdateQuota}} in acls.proto and add
{{update_quotas}} field to {{ACLs}} message;
In terms of how to start the deprecation cycle, my current proposal:
1. If not empty, values in {{update_quota}} will take precedence over values in
{{set_quotas}} and {{remove_quotas}} in actual authorization implementation;
2. the behavior will be documented in authorization.md;
3. The future quota update feature will only use {{update_quotas}} in ACL.
At the end of the deprecation cycle, we will drop the {{set_quotas}} and
{{remove_quotas}} from ACLs, and any {{--acl}} flag input with such fields will
not be valid input anymore.
(An alternative would be more aggressive in the beginning and reject
co-existence of non empty {{update_quotas}} vs
{{set_quotas}}/{{remove_quotas}}, but I'm not sure it's in the best interest of
the operators.)
[~adam-mesos] [~alexr], can you confirm this sounds like the right plan?
> 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)
