Minor Description
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.