strange behaviour: Task status -> error-> finished

[Olivier Sallou]

Hi 
I found a strange behaviour on a cluster that I do not understand. I do not 
have access to mesos logs (not in my cluster), but anyone faced this before ? 
My framework uses Docker containerizer. We faced a task that sent TASK_ERROR to 
the framework (why not), but in reality the Docker executed correctly on mesos 
slave, then we received a TASK_FINISHED. 
So mesos detected an error with task but it detected anyway the end of the task 
sending the finished event at the end. 

How mesos can detect an error but still watching the task and detect its end ? 

Here are my framework logs: 
2017-09-17 01:06:35,447 DEBUG [godocker-scheduler][Thread-1] Task 17820-0 is in 
state TASK_RUNNING 
2017-09-17 01:06:46,286 DEBUG [godocker-scheduler][Thread-1] Task 17820-0 is in 
state TASK_ERROR 
2017-09-17 02:13:44,537 DEBUG [godocker-scheduler][Thread-1] Task 17820-0 is in 
state TASK_FINISHED 

Unfortunalty I did not log the "reason" of the ERROR, so I do not know what 
occured, and cannot at this stage reproduce manually the use case. 

Can we have "non terminal" errors, from mesos point of view, where task should 
not be considered as over? 

Thanks 

Olivier 

[RESULT][VOTE] Release Apache Mesos 1.4.0 (rc5)

[Kapil Arya]

Hi all,

The vote for Mesos 1.4.0 (rc5) has passed with the following votes.

+1 (Binding)
--
Vinod Kone
Kapil arya
Anand Mazumdar

There were no 0 or -1 votes.

Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/1.4.0

It is recommended to use a mirror to download the release:
http://www.apache.org/dyn/closer.cgi

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.4.0

The mesos-1.4.0.jar has been released to:
https://repository.apache.org

The website (http://mesos.apache.org) will be updated shortly to reflect
this release.

Thanks,
Anand and Kapil

Re: [VOTE] Release Apache Mesos 1.4.0 (rc5)

[Anand Mazumdar]

+1 (binding)

make check passed on Ubuntu 16.04

-anand

On Fri, Sep 15, 2017 at 2:12 PM, Kapil Arya  wrote:

> +1 (binding)
>
> Internal CI with Centos 6/7, Fedora 23, Debian 8, and Ubuntu 12/14/16.
>
> On Fri, Sep 15, 2017 at 5:08 PM, Vinod Kone  wrote:
>
>> Ok. Looks like a test issue per https://reviews.apache.org/r/60467/
>>
>> +1(binding)
>>
>> On Fri, Sep 15, 2017 at 12:16 PM, Michael Park  wrote:
>>
>>> Vinod, regarding MESOS-7729
>>> :
>>>
>>> I found MESOS-6345  
>>> related
>>> to persistent volume framework, which leads me to believe that this is not
>>> new.
>>>
>>> Thanks,
>>>
>>> MPark
>>>
>>> On Tue, Sep 12, 2017 at 12:01 PM Vinod Kone 
>>> wrote:
>>>
 Tested this on ASF CI.

 Saw 3 flaky tests.

 https://issues.apache.org/jira/browse/MESOS-7729
 

 https://issues.apache.org/jira/browse/MESOS-7971
 https://issues.apache.org/jira/browse/MESOS-7972

 The first one was a known (since 1.4.0) flaky test with a double free
 corruption. @Kapil and @MPark can you verify that this is an issue with
 the
 test and not the source code? Once verified, I'll give a +1.

 *Revision*: b3fd2e7ab26e118222fe18af4b92c53a3c01e6cc

- refs/tags/1.4.0-rc5

 Configuration Matrix gcc clang
 centos:7 --verbose --enable-libevent --enable-ssl autotools
 [image: Success]
 
 [image: Not run]
 cmake
 [image: Success]
 
 [image: Not run]
 --verbose autotools
 [image: Failed]
 
 [image: Not run]
 cmake
 [image: Success]
 
 [image: Not run]
 ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
 [image: Success]
 
 [image: Success]
 
 cmake
 [image: Success]
 
 [image: Success]
 
 --verbose autotools
 [image: Success]
 
 [image: Success]
 
 cmake
 [image: Failed]