[jira] [Commented] (MESOS-3988) Implicit roles
[ https://issues.apache.org/jira/browse/MESOS-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15030801#comment-15030801 ] Yong Qiao Wang commented on MESOS-3988: --- In Mesos, lots of concept are around with role, such as quota, static/dynamic reservation, weight, etc. I think it is a centre concept, why we need to relax it? Are there some detailed user requirement for this project, if we relax the concept of role, somethings will become confused: 1. As a framework developer, if a framework can register with any role, why I need to aware it? Will we plan to remove role parameter from FrameworkInfo? 2. As a cluster operator, if I do not know what role will be used by end users/frameworks , how to configure quota, ACLs for register_frameworks action and static reservation? 3. In Mesos, the role which is used to determine what resources frameworks can use, if the static role list is removed, then how to define the resource plan for cluster admin? 4. In the traditional DRF Allocator, the total number of roles affects each role's fair share of the Mesos cluster, so if framework can register with any role, and master does not check it, then how to control and guarantee the fair share? 5. For dynamic ACLs/Weights, do we will configure it with any role(because role list will be removed in implicit roles project)? then the configured role will be provided to framework to use, is it right? if yes, I think it seems contradictory, we do not relax the role concept, and only merge the role configuration and Weights/ACLs configuration together, I think it is complex and does not easy understanding for end user. According to my understanding, role concept does not be relax in this design, we just put it in a number of places for management, for example, we can configure roles in ACLs management or Weights management endpoints, and will persist roles in ACLs or Weights replicated log, and frameworks can only use the roles configured in ACLs or Weights to apply the related policy. So I still proposed the centralized management method in MESOS-3177. > Implicit roles > -- > > Key: MESOS-3988 > URL: https://issues.apache.org/jira/browse/MESOS-3988 > Project: Mesos > Issue Type: Epic >Reporter: Neil Conway >Assignee: Neil Conway > Labels: mesosphere, roles > > At present, Mesos uses a static list of roles that are configured when the > master starts up. This places some severe limitations on how roles can be > used (e.g., changing the set of roles requires restarting all the masters). > As an alternative (or a precursor) to implementing full-blown dynamic roles, > we could instead relax the concept of roles, so that: > * frameworks can register with any role (subject to ACLs/authz) > * reservations can be made for any role > Open questions, at least to me: > * This would mean weights cannot be configured dynamically. Is that okay? > * Is this feature useful enough without dynamic ACL changes? > * If we implement this (+ dynamic ACLs), do we also need dynamic roles? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-3988) Implicit roles
[
https://issues.apache.org/jira/browse/MESOS-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15022024#comment-15022024
]
Guangya Liu commented on MESOS-3988:
One concern for this is that the role will be out of control in mesos cluster
because the end user may input some wrong words for roles.
If we can go with this direction, for the weight issues, perhaps we can enable
framework set roles plus weight, i,e, "role:weight", and we can define some
policy to decide how to get the weight if same roles configured different
weights, such as {{sum(weight)/n}} or using the biggest or smallest weight etc.
> Implicit roles
> --
>
> Key: MESOS-3988
> URL: https://issues.apache.org/jira/browse/MESOS-3988
> Project: Mesos
> Issue Type: Improvement
>Reporter: Neil Conway
> Labels: mesosphere, roles
>
> At present, Mesos uses a static list of roles that are configured when the
> master starts up. This places some severe limitations on how roles can be
> used (e.g., changing the set of roles requires restarting all the masters).
> As an alternative (or a precursor) to implementing full-blown dynamic roles,
> we could instead relax the concept of roles, so that:
> * frameworks can register with any role (subject to ACLs/authz)
> * reservations can be made for any role
> Open questions, at least to me:
> * This would mean weights cannot be configured dynamically. Is that okay?
> * Is this feature useful enough without dynamic ACL changes?
> * If we implement this (+ dynamic ACLs), do we also need dynamic roles?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-3988) Implicit roles
[ https://issues.apache.org/jira/browse/MESOS-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15023391#comment-15023391 ] Qian Zhang commented on MESOS-3988: --- [~neilc], we already have a ongoing project for dynamic role/weight: https://issues.apache.org/jira/browse/MESOS-3177, does it meet your requirement? > Implicit roles > -- > > Key: MESOS-3988 > URL: https://issues.apache.org/jira/browse/MESOS-3988 > Project: Mesos > Issue Type: Epic >Reporter: Neil Conway >Assignee: Neil Conway > Labels: mesosphere, roles > > At present, Mesos uses a static list of roles that are configured when the > master starts up. This places some severe limitations on how roles can be > used (e.g., changing the set of roles requires restarting all the masters). > As an alternative (or a precursor) to implementing full-blown dynamic roles, > we could instead relax the concept of roles, so that: > * frameworks can register with any role (subject to ACLs/authz) > * reservations can be made for any role > Open questions, at least to me: > * This would mean weights cannot be configured dynamically. Is that okay? > * Is this feature useful enough without dynamic ACL changes? > * If we implement this (+ dynamic ACLs), do we also need dynamic roles? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
