[
https://issues.apache.org/jira/browse/MESOS-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804289#comment-14804289
]
Cody Maloney commented on MESOS-3177:
-------------------------------------
Currently the mesos master doesn't keep track of roles it knows of explicitly,
just roles which it says it should know about passed in via the flag. Storing
them in the replicated log would be my preferred place to put / persist them.
If they are persisted in the repliacted log and that is the authoritative
source for them, I'd rather not have them be flags to the mesos master anymore,
as after first mesos master start those flags would be meaningless and lead to
a potentially bad user experience (I set the flags on mesos master but they
aren't applying!?!?!).
There is a `mesos-log` command that already exists, and it's been design
discussed some that initialization of the replicated log shouldn't be implicit
in master startup (Can potentially lead to bad cluster/error cases for some
node replacement scenarios).
I would suggest only allowing adding roles in v1. Removing roles will require
revoking offers, which sort of exists with inverse offers that recently became
available, but is going to be a lot of engineering.
For other things you're going to need a Mesos Shepherd going forward for more
design review, building out a proper design proposal, and getting things landed
in time.
> Make Mesos own configuration of roles/weights
> ---------------------------------------------
>
> Key: MESOS-3177
> URL: https://issues.apache.org/jira/browse/MESOS-3177
> Project: Mesos
> Issue Type: Improvement
> Components: master, slave
> Reporter: Cody Maloney
> Assignee: Thomas Rampelberg
> Labels: mesosphere
>
> All roles and weights must currently be specified up-front when starting
> Mesos masters currently. In addition, they should be consistent on every
> master, otherwise unexpected behavior could occur (You can have them be
> inconsistent for some upgrade paths / changing the set).
> This makes it hard to introduce new groups of machines under new roles
> dynamically (Have to generate a new master configuration, deploy that, before
> we can connect slaves with a new role to the cluster).
> Ideally an administrator can manually add / remove / edit roles and have the
> settings replicated / passed to all masters in the cluster by Mesos.
> Effectively Mesos takes ownership of the setting, rather than requiring it to
> be done externally.
> In addition, if a new slave joins the cluster with an unexpected / new role
> that should just work, making it much easier to introduce machines with new
> roles. (Policy around whether or not a slave can cause creation of a new
> role, a given slave can register with a given role, etc. is out of scope, and
> would be controls in the general registration process).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
