[jira] [Assigned] (MESOS-2657) Support multiple reasons in status update message.

["Greg Mann (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Greg Mann reassigned MESOS-2657:
--------------------------------

    Assignee:     (was: haosdent)

> Support multiple reasons in status update message.
> --------------------------------------------------
>
>                 Key: MESOS-2657
>                 URL: https://issues.apache.org/jira/browse/MESOS-2657
>             Project: Mesos
>          Issue Type: Improvement
>          Components: scheduler api
>            Reporter: Jie Yu
>            Priority: Major
>              Labels: api, observability
>
> Sometimes, a single reason in the status update message makes it very hard for frameworks to understand the cause of a status update. For example, we have REASON_EXECUTOR_TERMINATED, but that's a very general reason and sometime we want a sub-reason for that (e.g., REASON_CONTAINER_LAUNCH_FAILED) so that the framework can better react to the status update.
> We could change 'reason' field in TaskStatus to be a repeated field (should be backward compatible). For instance, for a containerizer launch failure, we probably need two reasons for TASK_LOST: 1) the top level reason REASON_EXECUTOR_TERMINATED; 2) the second level reason REASON_CONTAINER_LAUNCH_FAILED.
> Another example. We may want to have a generic reason when resource limit is reached: REASON_RESOURCE_LIMIT_EXCEEDED, and have a second level sub-reason: REASON_OUT_OF_MEMORY.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)