[
https://issues.apache.org/jira/browse/MESOS-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958536#comment-13958536
]
Adam B commented on MESOS-1188:
-------------------------------
I was originally thinking slaves.running/shutdown and
frameworks.running/completed, but now I like slaves.registered/unregistered and
frameworks.registered/completed since it's the (re)register message that adds a
framework/slave to the registered list, and the unregister message that removes
it.
I'm still debating if frameworks.completed is the right term, or if
frameworks.unregistered would be more appropriate (to match
slaves.unregistered). Completed frameworks currently have no way of being
reregistered, so it's more of an immutable archive state indicating that the
framework will not be registered/running again (under that frameworkId).
> 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)
