-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19383/
-----------------------------------------------------------
(Updated March 21, 2014, 12:56 a.m.)
Review request for mesos, Benjamin Hindman and Vinod Kone.
Changes
-------
No functional change, refactored Promise to Future and updated comments and
logging messages based on Vinod's feedback.
Removed dependent reviews.
Bugs: MESOS-764
https://issues.apache.org/jira/browse/MESOS-764
Repository: mesos-git
Description
-------
This implements the Registry-backed Master, with the following exceptions that
will be addressed in follow up changes:
-Note that the --registry_strict flag is enforced to be false in
master/main.cpp.
-Reconciliation remains unimplemented as before.
-Improvements can be made to killTask, specifically we should add SlaveID to
the message in order to drop fewer requests for unknown slaves.
-Orthogonally, this does not address MESOS-682.
I've updated 'deactivated' slaves to be a cache of SlaveIDs rather than UPIDs
as this was the intent originally (we were concerned about the unbounded growth
of the set, but cache<SlaveID, Nothing> keeps a fixed capacity).
Diffs (updated)
-----
src/master/constants.hpp cdaaad060d4ee777f8b0838b63c0fd031da861ea
src/master/constants.cpp 18548834468243bef8ae090f70363e2b9f571ac5
src/master/master.hpp a37a2a2fa3713b8251eb318dfb45e0793cb344ff
src/master/master.cpp 3b28f72be2016997e30649d2b12ed0e8f1a57dd5
src/messages/messages.proto c26a3d0e69bbbd447c859cf175c139ab8948fde2
src/slave/slave.cpp d8d3e0fa54972201d72b2650ec0ba922a4912d54
Diff: https://reviews.apache.org/r/19383/diff/
Testing
-------
This change preserves the previous semantics and so all existing tests pass.
This is because the Registrar can only operate in a "non-strict" manner.
An unfortunate effect of this change is that many tests run slower due to the
fact that messages are dropped while we're recovering, an alternative approach
here would be to re-enqueue *all* incoming messages through recover(). However,
this adds queuing delay to each message processed in the Master and the
performance implications of this are not well understood for large clusters.
Thanks,
Ben Mahler
