mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam B (JIRA)" <>
Subject [jira] [Created] (MESOS-1188) Rename slaves/frameworks.activated/deactivated
Date Thu, 03 Apr 2014 04:56:25 GMT
Adam B created MESOS-1188:

             Summary: Rename slaves/frameworks.activated/deactivated
                 Key: MESOS-1188
             Project: Mesos
          Issue Type: Improvement
          Components: master
            Reporter: Adam B
            Assignee: Adam B
            Priority: Minor

The "deactivate" terminology for slaves is especially confusing because "disconnecting" a
slave is analagous to "deactivating" a framework.

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
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 state and deactivateFramework message/action. (Or perhaps
registered/unregistered? Or up/down? Or running/removed?)

Here are the framework states:
A. Active: Framework exists in frameworks.activated,; goes inactive
on exited().
B. Inactive: Framework exists in frameworks.activated,; 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

View raw message