[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15279545#comment-15279545
]
Zhitao Li commented on MESOS-5155:
----------------------------------
[~alexr], so this is my understanding of your answer:
1) We will not try to implement quota update in the same release of
consolidation of quota authorization. (This is fine for me, just confirming the
plan);
2) Because the upgrade path is new binary and old ACL flag, new code needs to
construct both {{UPDATE_QUOTA_WITH_ROLE}} and {{DESTROY_QUOTA_WITH_PRINCIPAL}}
actions, send *each action* to (local) authorizer separately, and merge the
results with a boolean operator (*AND* or *OR*). Because one and only one ACL
list is an empty list, one of the result is always {{acls.permissive()}}, so we
need to use *AND* if {{acls.permissive()}} == true, and *OR* if
{{acls.permissive()}}==false. *Implementing this perfectly probably requires
adding more code to {{Authorizer}} interface.*
I tried to put up a test diff for a variance of Option 2, which completely
ignores {{remove_quotas}} and takes {{set_quotas}} as fallback if
{{update_quotas}} is empty. It is pretty easy to implement.
> 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)
