Discount code for MesosCon EU - Fees go up Sep. 25th

[Judith Malnick]

Hi everyone,

Use *MCEUMU20* to get 20% off your registration fee MesosCon Europe
(October 25-27th in Prague). Late registration starts on September 25th so
register  before
then to save $100.

The schedule for the conference looks amazing! Apache Mesos users including
Yelp, Twitter, Houghton Mifflin Harcourt, Criteo, OpenTable, Allegro,
Tunstall Nordic, and Charbeat will be sharing their operational experience.
Engineers from Adobe, SDL, Number 4, and Mesosphere will be talking about
Deep and Machine Learning on GPUs. Rich Bowen of RedHat will be giving a
keynote on the Apache Way .

This year's MesosCons are organized into tracks to make it easier to choose
which talks to attend. The MesosCon EU tracks include:

   - DevOps + Ops  
   - Frameworks 
   - Machine Learning + SMACK
   
   - Mesos Internals
   
   - SMACK 
   - Users + Ops
   


If you're on the fence about going, I highly recommend it! The MesosCon
North America talks were fantastic, and the conversations between users
were informative and inspiring! Don't miss MesosCon EU.

Register here! 

All the best,
Judith
-- 
Judith Malnick
DC/OS Community Manager
310-709-1517

Re: Collect feedbacks on TASK_FINISHED

[James Peach]

> On Sep 21, 2017, at 10:12 PM, Vinod Kone  wrote:
> 
> 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  wrote:
> 
>> Hi Folks,
>> 
>> 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.
>> 
>> This seems incorrect because we thought it should be TASK_KILLING ->
>> TASK_KILLED, that's why we filed a ticket 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.
>> 
>> Please let us know your thoughts on this issue, thanks!
>> 
>> 
>> Regards,
>> Qian Zhang
>>