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 >
