Skip to content

Update design to describe desired state REMOVE behavior for tasks #2485

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
anshulpundir merged 1 commit into from
Jan 17, 2018
Merged

Update design to describe desired state REMOVE behavior for tasks #2485

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions design/task_model.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -132,9 +132,18 @@ way to `RUNNING`. If a task exits without an error code, it moves to the
`COMPLETE` state. If it fails, it moves to the `FAILED` state instead.

A task may alternatively end up in the `SHUTDOWN` state if its shutdown was
requested by the orchestrator, the `REJECTED` state if the agent rejected the
requested by the orchestrator (by setting desired state to `SHUTDOWN`),
the `REJECTED` state if the agent rejected the
task, or the `ORPHANED` state if the node on which the task is scheduled is
down for too long.
down for too long. The orchestrator will also set desired state for a task not
already in a terminal state to
`REMOVE` when the service associated with the task was removed or scaled down
by the user. When this happens, the agent proceeds to shut the task down.
The task is removed from the store by the task reaper only after the shutdown succeeds.
This ensures that resources associated with the task are not released before
the task has shut down.
Tasks that were removed becacuse of service removal or scale down
are not kept around in task history.

The task state can never move backwards - it only increases monotonically.

Expand Down