From 46ee581f6d737743802fc680d1ba9a7cf0d1465d Mon Sep 17 00:00:00 2001 From: Nishant Totla Date: Tue, 16 Jan 2018 09:57:33 -0800 Subject: [PATCH] Update design to describe desired state REMOVE behavior for tasks Signed-off-by: Nishant Totla --- design/task_model.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/design/task_model.md b/design/task_model.md index 04eb5c40cb..5f76d3cefd 100644 --- a/design/task_model.md +++ b/design/task_model.md @@ -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.