[
https://issues.apache.org/jira/browse/MESOS-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987547#comment-13987547
]
Adam B commented on MESOS-1188:
-------------------------------
After further poking around, I definitely like 'registered' instead of
'activated', but 'unregistered' is too ambiguous, since it could imply that the
slave had never registered, which is not the case with this state. Instead, I
now recommend frameworks.completed (still appropriate) and slaves.removed
(since removeSlave puts it there, and addSlave takes it out and puts it back in
registered/activated).
Since we already have a DeactivateFrameworkMessage in the protobuf API, it
makes sense to use 'deactivate' and 'deactivated' to express whether the
allocator should consider a framework/slave in its allocations. I would suggest
'disabled' as another alternative here, if we wanted to choose something
different for BenH's new framework API, but 'deactivated' is fine once we
eliminate the confusion with the old slaves.deactivated state (now
slaves.removed).
Disconnect will henceforth refer specifically to a timeout/failure in the
connection between two components (framework disconnected from master, or
executor disconnected from slave), and will not imply anything else about how
either of those components respond to the disconnection.
> Rename slaves/frameworks.activated/deactivated
> ----------------------------------------------
>
> Key: MESOS-1188
> URL: https://issues.apache.org/jira/browse/MESOS-1188
> Project: Mesos
> Issue Type: Improvement
> Components: master
> Reporter: Adam B
> Assignee: Adam B
> Priority: Minor
> Labels: naming
>
> The "slaves.deactivated" terminology is confusing because one of these slaves
> has actually been removed/shutdown, more like a completed framework, whereas
> "deactivating" a framework is analagous to "disconnecting" a slave.
> The "frameworks.activated" terminology is also confusing, because a
> DeactivateFrameworkMessage does not remove the framework from
> frameworks.activated, it just marks framework.active=false and deactivates it
> in the allocator.
> I can identify the following 3 states for slaves:
> A. Connected: Slave exists in slaves.activated, slave.disconnected=false;
> disconnects when a checkpointing slave hits exited().
> B. Disconnected: Slave exists in slaves.activated, slave.disconnected=true;
> reconnects on reregisterSlave.
> C. Shutdown: Slave removed from slaves.activated, pid added to
> slaves.deactivated; readded to slaves.activated on registerSlave.
> I propose that we rename slaves.activated/deactivated to
> slaves.running/shutdown to avoid confusion with the framework.active state
> and deactivateFramework message/action. (Or perhaps registered/unregistered?
> Or up/down? Or running/removed?)
> Here are the (nearly analagous) framework states:
> A. Active: Framework exists in frameworks.activated, framework.active=true;
> goes inactive on exited().
> B. Inactive: Framework exists in frameworks.activated,
> framework.active=false; reactivated on reregister (if before failoverTimeout).
> C. Completed: Framework moved to frameworks.completed; never goes back.
> I propose that we rename frameworks.activated to frameworks.running (or
> registered?), because you shouldn't have an inactive slave in
> slaves.activated, but you could in slaves.running.
> I accept any/all naming feedback/suggestions. I just think we need to move
> away from the ambiguous/overloaded activated/deactivated terms.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
