[MESOS-764] Implement Master persistence using the Registrar.

• Type: Epic
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.19.0
• Component/s: master
• Labels: twitter
• Epic Name: Registrar
• Assignee: Benjamin Mahler
• Reporter: Benjamin Mahler
• Created: 23/Oct/13 23:40
• Updated: 02/Jul/15 18:43
• Resolved: 31/May/14 00:23

Description

Design document:
https://cwiki.apache.org/confluence/display/MESOS/Registrar+Design+Document

Using the registrar as a means for persistent, highly available storage of the slave information will allow us to recover slave information when a master is elected as a leader.

Having persistent slave information will allow the master to answer reconciliation requests from frameworks in a correct and reliable manner. There are currently cases where we cannot answer reconciliation requests in order to avoid providing an incorrect answer (hints in MESOS-295).

It will also ensure that when we inform the world that a slave is removed, we can enforce that as truth even with the presence of dropped messages and master failovers.

Issue Links

• blocks: MESOS-682 Master should properly consolidate "slaves" and "deactivated" maps
• blocks: MESOS-295 Allow new masters to have better understanding of cluster state
• is blocked by: MESOS-956 Add an "Sequence" abstraction to serialize callbacks.
• is blocked by: MESOS-980 Revisit Future discard semantics to enforce that transitions occur through a Promise.
• is blocked by: MESOS-983 Expose log coordinator demotion.
• is blocked by: MESOS-984 Implement "auto-initialization" of the Replicated Log.
• is blocked by: MESOS-1008 Reduce copying in stout / libprocess primitives {Try, Option, Result, Future}.
• is blocked by: MESOS-981 Implement Storage on the Replicated Log.
• is blocked by: MESOS-1123 Implement tests for stout/cache.hpp
• is related to: MESOS-1200 Add SlaveID to KillTaskMessage to provide feedback for unknown slaves.