[
https://issues.apache.org/jira/browse/MESOS-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam B resolved MESOS-1188.
---------------------------
Resolution: Fixed
Fix Version/s: 0.20.0
commit ba387dae077e3be029aa960bcdbf23cf7527c819
Author: Alexandra Sava <[email protected]>
Date: Thu Jul 17 01:02:09 2014 -0700
Renamed slaves/frameworks activated/deactivated
The existing terminology is confusing both for "slaves.deactivated" and
"frameworks.activated". Currently a deactivated slave actually
represents a removed/shutdown slave and "frameworks.activated" map holds
both activated and deactivated frameworks.
In order to make things look clear, rename the following:
* master.slaves.deactivated -> master.slaves.removed
* master.slaves.activated -> master.slaves.registered
* master.frameworks.activated -> master.frameworks.registered
* allocator.slaveDisconnect -> allocator.slaveDeactivate
* allocator.slaveReconnected -> allocator.slaveReactivated
Review: https://reviews.apache.org/r/23147
> 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: Alexandra Sava
> Priority: Minor
> Labels: naming
> Fix For: 0.20.0
>
>
> 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)
