[
https://issues.apache.org/jira/browse/MESOS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-2657:
-------------------------
Comment: was deleted
(was: www.rtat.net)
> 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, integration, 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)
