[
https://issues.apache.org/jira/browse/MESOS-3177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14740398#comment-14740398
]
Cody Maloney commented on MESOS-3177:
-------------------------------------
There hasn't been any design documentation building / development so far.
In my mind I've been thinking it of a "Before you start the mesos masters, you
create the initial replicated log state which contains the first set of roles
and weights to operate with". Then from that point on mesos has a "add_role"
and "remove_role" endpoints to manage them. Even better would be that if you
don't have authentication turned on, as mesos sees new roles it just adds them
(And as all things with that role disappear it removes them). If authentication
is turned on, the authentication mechanism effectively "permanently" owns all
the roles it defines (if it's just a static configuration file). If it's a
dynamic source / database then the interface to talk about ownership would
probably need to get more complicated.
> 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)
