[
https://issues.apache.org/jira/browse/MESOS-2657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175579#comment-16175579
]
James Peach commented on MESOS-2657:
------------------------------------
[[email protected]] [~jieyu] As part of the refactoring for MESOS-7963, I'm
planning to remove the multiple reasons in the {{ContainerTermination}}
message. I think the main use case for that was supporting multiple limitations
from isolators, but that never worked and I'm removing that as well :)
Please let me know if you see any problems with this.
> Support multiple reasons in status update message.
> --------------------------------------------------
>
> Key: MESOS-2657
> URL: https://issues.apache.org/jira/browse/MESOS-2657
> Project: Mesos
> Issue Type: Improvement
> Reporter: Jie Yu
> Assignee: haosdent
>
> 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
(v6.4.14#64029)
