Hi Benjamin, Yes that's what I meant: adding a new reason for such cascaded kill.
On Tue, Apr 10, 2018 at 1:17 PM, Benjamin Mahler <bmah...@apache.org> wrote: > Are you saying that there was no reason previously, and there would be a > reason after the change? If so, adding a reason where one did not exist is > safe from a backwards compatibility perspective. > > On Mon, Apr 9, 2018 at 10:32 AM, Zhitao Li <zhitaoli...@gmail.com> wrote: > >> Hi, >> >> We are considering adding a new reason to StatusUpdate::Reason >> <https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L2395>, >> to reflect the case when a task in a task group is killed cascaded: >> >> Currently, if a task fails in a task group, other active tasks in the >> same group will see *TASK_KILLED* without any custom reason. We would >> like to provide a custom reason like *REASON_TASK_GROUP_KILLED* to >> distinguish whether the task is killed upon request of scheduler or upon a >> cascaded failure. >> >> >> Question to framework maintainer: does any framework depends the value >> of this reason? If not, we probably can just change the reason without a >> opt-in mechanism from framework (i.e, a new framework capability). >> >> Please let me know if your framework as such a dependency. >> >> Thanks! >> >> >> -- >> Cheers, >> >> Zhitao Li >> > > -- Cheers, Zhitao Li
