mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jie Yu (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-2657) Support multiple reasons in status update message.
Date Thu, 23 Apr 2015 00:29:38 GMT

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

Jie Yu updated MESOS-2657:
--------------------------
    Description: 
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.

  was:
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.


> 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
>
> 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.3.4#6332)

Mime
View raw message