[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257557#comment-15257557
]
Zhitao Li commented on MESOS-5155:
----------------------------------
[~adam-mesos], I tried to implement the plan listed in option 1, but saw two
potential issues:
1. Once we implemented quota update in MESOS-4941 (which we plan to use
{{UPDATE_QUOTA_WITH_ROLE}} to guard), operator cannot upgrade to a version
safely without temporarily losing ACL on either update quota or set quota;
2. {{Master::QuotaHandler::authorizeRemoveQuota}} needs to have access to the
{{ACLs}}, so it can check which of {{removeQuotas}} or {{updateQuotas}} is
empty in input, because {{object}} will have different types. However, {{ACLs}}
is only parsed and stored in either {{LocalAuthorizer}} or external authorizer
module, and not exposed in the {{mesos::Authorizer}} interface right now. We
would need to modify {{mesos::Authorizer}} interface to either return {{ACLs}},
or return more information than {{Future<bool>}}.
Option 2 (which requires operator to provide {{ACLs.updateQuotas}} before
binary upgrade, and simply warn and ignore old fields if not empty) does not
have these problems, because we can simply cut implementation in
{{QuotaHandler}} onto new action. The downside here is that operator needs to
change {{--acls}} with unrecognized content first, and expect later binary
upgrade to pick up the new filed, although I guess this is required to pick up
any new action which requires ACLs.
Do you think we should still go with option 1? If yes, what's your suggestion
on implementing {{Master::QuotaHandler::authorizeRemoveQuota}}?
> 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)
