[
https://issues.apache.org/jira/browse/MESOS-3068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14643964#comment-14643964
]
Adam B commented on MESOS-3068:
-------------------------------
My understanding is that the Registrar is responsible for persisting cluster
state to the Registry, so those two are tightly coupled. You should either (a)
add your MaintenanceInfo to the Registry protobuf and let the existing
Registry/Registrar logic handle your use case, or (b) eschew the Registrar and
use the raw replicated log API (or state abstraction) instead.
Since you need to persist your not-too-frequent state changes and recover them
upon master failover, I think the Registrar/Registry is appropriate.
> Registry operations are hardcoded for a single key (Registry object)
> --------------------------------------------------------------------
>
> Key: MESOS-3068
> URL: https://issues.apache.org/jira/browse/MESOS-3068
> Project: Mesos
> Issue Type: Task
> Components: master, replicated log
> Reporter: Joseph Wu
> Assignee: Joseph Wu
> Labels: mesosphere
>
> This is primarily a refactoring.
> The prototype for modifying the registry is currently:
> {code}
> Try<bool> operator () (
> Registry* registry,
> hashset<SlaveID>* slaveIDs,
> bool strict);
> {code}
> In order to support Maintenance schedules (possibly Quotas as well), there
> should be an alternate prototype for Maintenance. Something like:
> {code}
> Try<bool> operation () (
> Maintenance* maintenance,
> bool strict);
> {code}
> The existing RegistrarProcess::update (src/master/registrar.cpp) should be
> refactored to allow for more than one key. If necessary, refactor existing
> operations defined in src/master/master.hpp (AdminSlave, ReadminSlave,
> RemoveSlave).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)