You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Vinod Kone (JIRA)" <ji...@apache.org> on 2014/01/22 05:23:20 UTC

[jira] [Commented] (MESOS-903) Store MasterInfo in ZK to enable master web UI redirection etc.

    [ https://issues.apache.org/jira/browse/MESOS-903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13878244#comment-13878244 ] 

Vinod Kone commented on MESOS-903:
----------------------------------

https://reviews.apache.org/r/17171/
https://reviews.apache.org/r/17172/
https://reviews.apache.org/r/17173/

I propose we include the first 2 reviews in 0.16.0 and the last one in 0.17.0 to make backwards compatible upgrade easier. Thoughts?

There will be another patch that adds "hostname" field to MasterInfo.

> Store MasterInfo in ZK to enable master web UI redirection etc.
> ---------------------------------------------------------------
>
>                 Key: MESOS-903
>                 URL: https://issues.apache.org/jira/browse/MESOS-903
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Yan Xu
>            Assignee: Vinod Kone
>             Fix For: 0.17.0
>
>
> Storing a ProtoBuf MasterInfo in ZK allows us to add more fields other than the PID to associate with the (leading) master so that other entities (e.g. the follower masters) get more information such as the public hostname.
> The current solution that BenH and I have worked out:
> ## Introduce Group::Membership::label for backwards compatibility.
> - Group: use the sequence number for membership `id` and `label_` for storing additional data. This way a ProtoBuf blob is never stored at the same path as a regular PID so that the backwards compatibility issue (parsing a PID string as ProtoBuf blob or vise versa) can be avoided.
> - Group::Membership will include a label field. Group::join() writes `label_sequence` as ZNode name: `info_sequence` stores MasterInfo and plain `sequence` stores PID.
> ## Current version (v0: 0.16)
> - Group operation ignores ZNodes whose names can't be parse into `int32`. So that when a slave is rolled back and reads from ZK which has v1 data, it ignores all the masters and stays idle.
> ## New version (v1: >= 0.17)
> - Roll slaves first. New slaves can work with old ZK data.
> - Master can be rolled back after slave roll.
> See more: https://gist.github.com/xujyan/796d2e10b8fbddaf7979



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)