I'm reluctant to introduce multiple role management mechanisms because of
mainly two reasons: avoid spreading our efforts and avoid confusion for
operators (legacy roles, implicit roles, dynamic roles).
Another thing is that after talking to some folks, I realized that the
blocker right now is that people cannot add roles on the fly. Hence
operators can hardly use features like quota or dynamic reservations. Hence
I would rather enable adding roles on the fly _now_ and refine it later.
Implicit roles seem less coupled with other stories involving roles
(weights, ACLs, quotas) and allow us to ship an MVP sooner (this my
intuition).
> 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.
After talking to Neil about that, I have the following picture in mind. All
roles exist, but some are currently "visible". A role is "visible" to the
master if it is mentioned at least once (think reference counting smart
pointers): there is an ACL mentioning this role, a quota for the role is
set, a framework is registered with this role, and so on. IIUC visible
roles are equivalent to current roles stored in `Master::Role` struct (or
`RoleInfo`).
To the second part of Adam's answer: What does dynamic `RoleInfo` mean?
Currently, it's just a pair `<role, weight>` which is actually dynamic role
weight : ). I'm also not sure we should update `RoleInfo` with any
role-related information. For example, we already do not store role quotas
there, neither dynamically reserved resources are listed there.
Now, the trickiest part IMO is to do "reference counting" right: maintain a
full list of visible roles without orphans (do not "leak" roles if you
want). However, I think, it's a reasonable engineering effort for
simplicity for operators.
> 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.
Opting for implicit roles allows us to free engineering forces to focus on
dynamic ACLs and dynamic role weights!
> > 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.
Dynamic roles are persisted in the master *and* implicitly in the cluster.
Master tracks for example quotas and role weights, while re-registering
frameworks — roles with which they register.
> > 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.
Why can't we have a single endpoint for viewing and manipulating implicit
roles? Imagine the following sequence of operator requests:
* GET /roles -> {[{name: "prod"}, {name: "hdfs"}]}
* POST /roles/add { name: "test", weight: "0.1" } -> OK
* GET /roles -> {[{name: "prod"}, {name: "hdfs"}, {name: "test", weight:
"0.1"]}
I would suggest to join efforts and focus on implicit roles, gather user
feedback and revisit role management later on if needed.
Thanks,
AlexR
On Fri, Dec 4, 2015 at 11:30 AM, Adam Bordelon <[email protected]> wrote:
> 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 <[email protected]>
> 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 <[email protected]>
> > 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 <[email protected]>
> > wrote:
> > >
> > >> On Mon, Nov 30, 2015 at 6:53 PM, YongQiao Wang <
> [email protected]
> > >
> > >> 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
> > >>
> > >
> > >
> >
>
