[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15240889#comment-15240889
]
Adam B commented on MESOS-5155:
-------------------------------
Thinking in CRUD terms, if we're merging create/delete into update, will we
also need a READ_QUOTA_... Action soon too?
If we move toward an actual RESTful API, should we have a separate action for
each of POST/GET/PUT/DELETE verbs on the /quota endpoint?
As for deprecation, we have a few options:
1. Good: Fail master startup if we find both update_quota and set/remove_quota
set anywhere in the --acl flag. Admin should update all ACLs to the new format
at the same time.
2. OK: Allow old and new ACLs, but if we find both types anywhere in --acl, log
a warning and ignore all set/remove_quota ACLs. Users might ignore the warning
and be surprised that the old ACLs no longer apply.
3. Weird: Allow old and new ACLs, but if we find both types on the same
user+role combo, log a warning and only use the new ACL. If a user+role combo
only has an old ACL, we accept that too. This would be difficult to reason
about which rules apply when.
4. Bad: Silently ignore old ACLs, without a deprecation warning. Deprecations
must be logged.
5. Bad: Reject old ACLs, even if no new ACLs are present. Not
backwards-compatible.
> 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)
