[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15257410#comment-15257410
]
Adam B commented on MESOS-5155:
-------------------------------
Excellent point. Operators must be able to upgrade their clusters live without
losing access control. But this can still be achieved with option 1. I only
stated that we should fail master startup if we find *both* old and new in
--acls. As AlexR suggests, if only the old format is specified, a deprecation
warning will be printed.
1. Start with old ACL fields/values and old binaries. Works without warnings.
2. Upgrade to new binary, keep old ACLs. Master logs deprecation warning, but
works with old ACLs.
3. Upgrade flags to new ACLs. New master works without warnings with new ACLs.
In some future (>6 months) release, we will remove the deprecated format and
the warning. From that release on, only the new ACLs will be accepted.
> 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)
