mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam B (JIRA)" <>
Subject [jira] [Commented] (MESOS-1188) Rename slaves/frameworks.activated/deactivated
Date Fri, 02 May 2014 09:51:14 GMT


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:
>             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
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 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,; 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