Mailing-List: contact user-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@mesos.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Collect feedbacks on TASK_FINISHED
From: James Peach <jorgar@gmail.com>
In-Reply-To: <CANntcz6_QSSe4Ma1Pof52tzHO=LDRo34+26cd__e7TOS4kuF3Q@mail.gmail.com>
Date: Fri, 22 Sep 2017 00:27:11 -0700
Cc: user <user@mesos.apache.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C84A5350-B7AC-4C90-82E7-8F108FA89F1B@gmail.com>
References: <CABY6VObgAELbJW9SoQ2TNSWmb59xw-WyBC+CTcuegCjE=Uj19g@mail.gmail.com>
 <CANntcz6_QSSe4Ma1Pof52tzHO=LDRo34+26cd__e7TOS4kuF3Q@mail.gmail.com>
To: dev <dev@mesos.apache.org>
archived-at: Fri, 22 Sep 2017 07:27:11 -0000


> On Sep 21, 2017, at 10:12 PM, Vinod Kone <vinod@mesosphere.io> wrote:
>=20
> I think it makes sense for `TASK_KILLED` to be sent in response to a =
KILL
> call irrespective of the exit status. IIRC, that was the original =
intention.

Those are the semantics we implement and expect in our scheduler and =
executor. The only time we emit TASK_KILLED is in response to a =
scheduler kill, and a scheduler kill always ends in a TASK_KILLED.

The rationale for this is
1. We want to distinguish whether the task finished for its own reasons =
(ie. not due to a scheduler kill)
2. The scheduler told us to kill the task and we did, so it was =
TASK_KILLED (irrespective of any exit status)

> On Thu, Sep 21, 2017 at 8:20 PM, Qian Zhang <zhq527725@gmail.com> =
wrote:
>=20
>> Hi Folks,
>>=20
>> I'd like to collect the feedbacks on the task state TASK_FINISHED.
>> Currently the default and command executor will always send =
TASK_FINISHED
>> as long as the exit code of task is 0, this cause an issue: when =
scheduler
>> initiates a kill task, the executor will send SIGTERM to the task =
first,
>> and if the task handles SIGTERM gracefully and exit with 0, the =
executor
>> will send TASK_FINISHED for that task, so we will see the task state
>> transition: TASK_KILLING -> TASK_FINISHED.
>>=20
>> This seems incorrect because we thought it should be TASK_KILLING ->
>> TASK_KILLED, that's why we filed a ticket MESOS-7975
>> <https://issues.apache.org/jira/browse/MESOS-7975> for it. However, I =
am
>> not very sure if it is really a bug, because I think it depends on =
how we
>> define the meaning of TASK_FINISHED, if it means the task is =
terminated
>> successfully on its own without external interference, then I think =
it does
>> not make sense for scheduler to receive a TASK_KILLING followed by a
>> TASK_FINISHED since there is indeed an external interference (killing =
task
>> is initiated by scheduler). However, if TASK_FINISHED means the task =
is
>> terminated successfully for whatever reason (no matter it is killed =
or
>> terminated on its own), then I think it is OK to receive a =
TASK_KILLING
>> followed by a TASK_FINISHED.
>>=20
>> Please let us know your thoughts on this issue, thanks!
>>=20
>>=20
>> Regards,
>> Qian Zhang
>>=20