[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15289240#comment-15289240
]
Alexander Rukletsov commented on MESOS-5155:
{noformat}
Commit: a28917f188183a4be1c974fc61ef20797cf255af [a28917f]
Author: Zhitao Li
Date: 18 May 2016 16:17:11 CEST
Committer: Alexander Rukletsov
Commit Date: 18 May 2016 18:21:40 CEST
Used UPDATE_QUOTA_WITH_ROLE for both quota set and remove.
To consolidate authorization actions for quota, we introduce a new
authorization action `UPDATE_QUOTA_WITH_ROLE` and corresponding
ACL. They new action and ACL should be used instead of now deprecated
`SET_QUOTA_WITH_ROLE` and `DESTROY_QUOTA_WITH_PRINCIPAL`. Until the
end of the deprecation cycle, we will be using both combinations by
querying the authorizer twice.
Review: https://reviews.apache.org/r/47399/
{noformat}
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15273864#comment-15273864
]
Adam B commented on MESOS-5155:
---
[~zhitao], see also MESOS-5336 for authorizing GET /quota
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267152#comment-15267152
]
Alexander Rukletsov commented on MESOS-5155:
[~zhitao], Let me try to answer these questions:
1. IIUC, you are saying that operators won't be able to use update quota and
old set/remove authz actions together. I think this is fine, because we
introduce update quota *after* introducing a new authz action. We can even
motivate operators to migrate faster ; ).
2. IIUC this one, we can add an overload for
{{Master::QuotaHandler::authorizeRemoveQuota()}} which takes a principal and a
role, check *both* for now, and remove the current overload after deprecation
cycle. Does this make sense?
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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}}.
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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257139#comment-15257139
]
Zhitao Li commented on MESOS-5155:
--
[~alexr] [~adam-mesos] I noticed that previous handling of deprecation for
shutdown_framework -> teardown_framework followed more with option 2 from
Adam's list (warn instead of fail if value are specified in both fields, and
ignore values from deprecated field).
The benefit of this option is a clear upgrade path for operator w/o losing ACL
guard at any moment:
1. Rollout values for both old and new fields (I assume new field will be
dropped in {{protobuf::parse}} because it's unknown value);
2. Rollout new binary version, new value will take effect instead of the old
one;
3. Once stabilized, remove old value within deprecation cycle.
In option 1, I don't think there is a way to do this w/o either turning off ACL
for quota in upgrade window, or forcing coordinated upgrade for both --acls
flag and binary version (which is not easy if operator has multiple clusters).
What do you think?
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15245342#comment-15245342
]
Alexander Rukletsov commented on MESOS-5155:
I'd also vote for Adam's option 1, with the addition that if only old types are
used, a deprecation warning is issued.
Regarding `READ_QUOTA` — I think we can add it later if necessary. As [~zhitao]
points out, we don't currently have ACLs for read-only actions.
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15241500#comment-15241500
]
Zhitao Li commented on MESOS-5155:
--
READ_QUOTA is not protected by ACL today. I haven't seen consistent design or
document about additional authorization and authentication about readonly http
endpoints today.
So, my initial proposal matches your "OK" option while my alternative proposal
matches the "Good" option. I assume you want to make the operators move faster
in this deprecation cycle. I'm fine with that idea.
I'll start working on this today/tomorrow.
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235759#comment-15235759
]
Alexander Rukletsov commented on MESOS-5155:
I'm afraid so, because we also have to update ACLs which we've published in
0.27.
> 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)
[jira] [Commented] (MESOS-5155) Consolidate authorization actions for quota.
[
https://issues.apache.org/jira/browse/MESOS-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235662#comment-15235662
]
Adam B commented on MESOS-5155:
---
+1 to getting rid of DESTROY_QUOTA_WITH_PRINCIPAL, but has it made it into a
release already? Do we need to put it through a deprecation cycle?
> 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)
