Thanks for the discussion so far. Rereading it has helped me understand the
relationship/overlap between these two proposals. Here are my thoughts.
TL;DR: Let's do both! Not specifying --roles (or ACLs) should mean that any
role can register. Let's also improve the /roles endpoint to
update/remove/list Role metadata and persist it (although not for just
adding/removing explicitly allowed role names).
Please keep in mind a previously unmentioned user story: "As a cluster
admin, I would like to allow authorized principals to register as many
frameworks+roles as necessary, without manual admin intervention, so that
each framework can create dynamic reservations and persistent volumes that
aren't shared with other frameworks that happen to have the same role."
At the very beginning of this thread (Nov 26), Neil said about Implicit
Roles:
> In a sense, "all roles" exist, so there is no need to store the set of
legal roles or provide endpoints to modify them.
- As I rethink this, I tend to disagree. Even with implicit/unknown roles
allowed by default ("all roles exist"), it may still be necessary to use
ACLs to specify the set of legal roles, and although we may not need
endpoints just to add/remove role names, we will need endpoints to
update/remove/list RoleInfos. Maybe we should think of these differently as
two complementary features: Implicit Roles Allowed by Default, and Dynamic
RoleInfos.
And now I'll respond to Yong's most recent points on Implicit Roles:
> 1. Does not need a specified endpoint for role management, but more
endpoints should be provided to manage role's related object, such as the
dynamic management for Weight, Grace Period (which is involved by
Optimistic Offers), etc.
+ Agreed. Implicit Roles on their own provide some value to smaller,
trusting companies, but we still need Dynamic ACLs and Dynamic Weights
before Roles in general are enterprise-ready. Even the Dynamic Roles
proposal includes Dynamic Weights. And Dynamic ACLs are in increasing
demand for other reasons.
> 2. Role will be persisted in multiple places. For example, role should be
persist in replicated log when we have dynamic weight, and role also need
be persisted when we have dynamic Grace Period, etc.
- Not necessarily. Firstly, implicit/unspecified roles with default values
don't need to be persisted anywhere. And if a user wants to set non-default
RoleInfo settings, they can, and then that info must be persisted, whether
there's a framework associated with that role or not. But nothing says that
the role (name) must be persisted separately for weights, quota, grace
period, etc. ACLs are another story, since they are much broader than just
roles, and they may actually be sourced externally, e.g. LDAP.
> 3. Role validation (such as to avoid the typos) depends on ACLs;
+ Correct (at least once we deprecate --roles). But how is managing a list
in an ACL different from managing an explicit --roles list, or whatever
goes into your addRole endpoint? And even with dynamic roles, there's the
chance that the role spelling in the ACL differs from that in the roles
list.
> 4. As an operator, s/he must have more knowledges to use multiple
endpoints to manage role's related objects. and the operator must guarantee
consistency when configuring ACLs, weights, Grace Period, quota, etc.
+ Good point. If we're going to have more and more metadata associated with
roles, it may make sense to be able to query and modify this data as a
unit. Even if we adopt the idea that an unspecified role is implicitly
allowed and given default metadata if it isn't explicitly disallowed by
ACLs, we could still use the Dynamic Roles proposal's update/remove/list
endpoints for those roles where we did express metadata. Note: The
'addRole' operation becomes identical to 'updateRole' if you don't check
whether the role previously existed.
And for Yong's Dynamic Roles points:
> 1. Needs to enhance the exist endpoint /roles to support
add/update/remove a role, and operator can only use this one endpoint to
manage all objects (e.g. weight, Grace Period, etc.) which related with
role.
+ Clarification: I believe you mean that "only operators can use this
endpoint", meaning that a framework could not add/update/remove its own
role.
> 2. Role information will only be persisted in one replicated log (Plan to
persist RoleInfo when call /roles to add role).
+ I don't think anybody was suggesting otherwise, even with Implicit Roles.
Implicit Roles itself has no need for persistence. That's up to Dynamic
Weights/ACLs/whatever.
> 3. Keep a valid role list in Mesos, and which can be used to prevent the
typos and can help to check the correctness when operator configuring
ACLs, weights, Grace Period, quota, etc.
- I don't think preventing typos is a strong motivating use case. But since
we'll still have to support --roles for a while, it can still be used by
anybody not satisfied with using ACLs to declare the list of allowed roles.
In response to Yong's concern about ACLs:
> My concern is that Implicit Roles and ACLs are independent functions,
ACLs is focus on the access control rather than prevent a invalid role. For
example, if the principal is incorrect, then the authorization will also
failed when register framework. In addition, as you mean, Implicit roles
must depend on ACLs? If without ACLs, Implicit roles can work well?
We'll really only be changing the behavior if --roles is not specified,
which previously would have meant that no roles are allowed. If that's
really the desired use case, then it can be expressed through ACLs. More
likely, somebody setting up a dev/test cluster won't know that they need to
set --roles, and may try to register a framework with a new role and expect
it to succeed automatically. So, without ACLs or explicit --roles/weights,
I suspect (based on actual reported user confusion) that many naive users
would expect to be able to register with any role.
Thanks for reading this far,
-Adam-
On Tue, Dec 1, 2015 at 1:10 AM, YongQiao Wang <jamesyongq...@gmail.com>
wrote:
> Some design analyse between Implicit Roles and Dynamic Roles:
>
> For Implicit Roles:
> 1. Does not need a specified endpoint for role management, but more
> endpoints should be provided to manage role's related object, such as the
> dynamic management for Weight, Grace Period (which is involved by
> Optimistic Offers), etc.
> 2. Role will be persisted in multiple places. For example, role should be
> persist in replicated log when we have dynamic weight, and role also need
> be persisted when we have dynamic Grace Period, etc.
> 3. Role validation (such as to avoid the typos) depends on ACLs;
> 4. As an operator, s/he must have more knowledges to use multiple endpoints
> to manage role's related objects. and the operator must guarantee
> consistency when configuring ACLs, weights, Grace Period, quota, etc.
>
> For Dynamic Roles:
> 1. Needs to enhance the exist endpoint /roles to support add/update/remove
> a role, and operator can only use this one endpoint to manage all objects
> (e.g. weight, Grace Period, etc.) which related with role.
> 2. Role information will only be persisted in one replicated log (Plan to
> persist RoleInfo when call /roles to add role).
> 3. Keep a valid role list in Mesos, and which can be used to prevent the
> typos and can help to check the correctness when operator
> configuring ACLs, weights, Grace Period, quota, etc.
>
> So I think the model of Dynamic Roles is easy to understand and operate.
> This is only my understanding, welcome any other comments.
>
> On Tue, Dec 1, 2015 at 5:05 PM, YongQiao Wang <jamesyongq...@gmail.com>
> wrote:
>
> > @Neil, My concern is that Implicit Roles and ACLs are independent
> > functions, ACLs is focus on the access control rather than prevent a
> > invalid role. For example, if the principal is incorrect, then
> > the authorization will also failed when register framework. In addition,
> as
> > you mean, Implicit roles must depend on ACLs? If without ACLs, Implicit
> > roles can work well?
> >
> > On Tue, Dec 1, 2015 at 2:44 PM, Neil Conway <neil.con...@gmail.com>
> wrote:
> >
> >> On Mon, Nov 30, 2015 at 6:53 PM, YongQiao Wang <jamesyongq...@gmail.com
> >
> >> wrote:
> >> >> 1. Choosing a role name
> >> >> 2. Configuring weights, ACLs, and quotas for the role.
> >> >> 3. Configuring applications/frameworks to register using that role.
> >> >
> >> > [Yong Qiao] If applications/frameworks do not follow your rules, and
> >> > register with another role, then how to prevent? and do we will still
> >> > create this undesirable role in Mesos? Maybe we can only relay on ACLs
> >> to
> >> > avoid this, but according to my understanding, ACLs is not required in
> >> > Mesos.
> >>
> >> Right -- with implicit roles, the proposal is to use ACLs to prevent a
> >> framework from registering as an undesirable role. ACLs are a
> >> general-purpose mechanism for determining whether a principal should
> >> be permitted to take an action, so it seems reasonable and consistent
> >> to use ACLs for this purpose.
> >>
> >> > In addition, I am not sure whether it is make sence to use ACLs for
> >> > role validation.
> >>
> >> Can you elaborate on your reasoning here?
> >>
> >> Thanks,
> >> Neil
> >>
> >
> >
>
