Re: [VOTE] Release Apache Mesos 0.24.1 (rc1)

[Adam Bordelon]

+1 (binding) Tested on CI for CentOS7, Fedora22, and Ubuntu 14.04.

On Tue, Sep 22, 2015 at 1:41 PM, Niklas Nielsen 
wrote:

> +1 (binding)
>
> On 21 September 2015 at 11:46, Vinod Kone  wrote:
>
>> +1 (binding)
>>
>> Tested on CI for CentOS5 and CentOS6.
>>
>> On Fri, Sep 18, 2015 at 6:21 PM, Adam Bordelon 
>> wrote:
>>
>>> Hi friends,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 0.24.1.
>>>
>>> 0.24.1 includes the following:
>>>
>>> 
>>> * [MESOS-2986] - Docker version output is not compatible with Mesos
>>> * [MESOS-3136] - COMMAND health checks with Marathon 0.10.0 are broken
>>>
>>> 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=0.24.1-rc1
>>>
>>> 
>>>
>>> The candidate for Mesos 0.24.1 release is available at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz
>>>
>>> The tag to be voted on is 0.24.1-rc1:
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.1-rc1
>>>
>>> The MD5 checksum of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz.md5
>>>
>>> The signature of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz.asc
>>>
>>> The PGP key used to sign the release is here:
>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>
>>> The JAR is up in Maven in a staging repository here:
>>> https://repository.apache.org/content/repositories/orgapachemesos-1068
>>>
>>> Please vote on releasing this package as Apache Mesos 0.24.1!
>>>
>>> The vote is open until Wed Sep 23 18:00 PDT 2015 and passes if a majority
>>> of at least 3 +1 PMC votes are cast.
>>>
>>> [ ] +1 I tested this package. Release it as Apache Mesos 0.24.1
>>> [ ] -1 Do not release this package because ...
>>>
>>> Thanks,
>>> -Adam-
>>>
>>
>>
>

Re: [VOTE] Release Apache Mesos 0.23.1 (rc1)

[Adam Bordelon]

+1 (binding) Tested on CI for CentOS7, Fedora22, and Ubuntu 14.04.

On Wed, Sep 23, 2015 at 10:25 AM, haosdent  wrote:

> +1 test on Ubuntu 14.04
>
> On Tue, Sep 22, 2015 at 9:06 AM, Adam Bordelon  wrote:
>
>> Hi friends,
>>
>> Please vote on releasing the following candidate as Apache Mesos 0.23.1.
>>
>> 0.23.1 is a bug fix release and includes the following:
>>
>> 
>> * [MESOS-2986] - Docker version output is not compatible with Mesos
>> * [MESOS-3136] - COMMAND health checks with Marathon 0.10.0 are broken
>>
>> 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=0.23.1-rc1
>>
>> 
>>
>> The candidate for Mesos 0.23.1 release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz
>>
>> The tag to be voted on is 0.23.1-rc1:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.1-rc1
>>
>> The MD5 checksum of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.asc
>>
>> The PGP key used to sign the release is here:
>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>
>> The JAR is up in Maven in a staging repository here:
>> https://repository.apache.org/content/repositories/orgapachemesos-1070
>>
>> Please vote on releasing this package as Apache Mesos 0.23.1!
>>
>> The vote is open until Thu Sep 24 18:00 PDT 2015 and passes if a majority
>> of at least 3 +1 PMC votes are cast.
>>
>> [ ] +1 I tested this package. Release it as Apache Mesos 0.24.1
>> [ ] -1 Do not release this package because ...
>>
>> Thanks,
>> -Adam-
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

[VOTE] Release Apache Mesos 0.22.2 (rc1)

[Adam Bordelon]

Hi friends,

Here's another docker patch release candidate for you! Please vote on
releasing the following candidate as Apache Mesos 0.22.2.

0.22.2 is a bug fix release and includes the following:

* [MESOS-2986] - Docker version output is not compatible with Mesos

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=0.22.2-rc1


The candidate for Mesos 0.22.2 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz

The tag to be voted on is 0.22.2-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.2-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1072

Please vote on releasing this package as Apache Mesos 0.22.2!

The vote is open until Mon Sep 28 18:00 PDT 2015 and passes if a majority
of at least 3 +1 PMC votes are cast.

[ ] +1 I tested this package. Release this package as Apache Mesos 0.22.2
[ ] -1 Do not release this package because ...

Thanks,
-Adam-

Re: [VOTE] Release Apache Mesos 0.22.2 (rc1)

[Adam Bordelon]

+1 (binding) Tested on CI for CentOS7, Fedora22, and Ubuntu 14.04.

On Thu, Sep 24, 2015 at 12:10 AM, Adam Bordelon  wrote:

> Hi friends,
>
> Here's another docker patch release candidate for you! Please vote on
> releasing the following candidate as Apache Mesos 0.22.2.
>
> 0.22.2 is a bug fix release and includes the following:
>
> 
> * [MESOS-2986] - Docker version output is not compatible with Mesos
>
> 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=0.22.2-rc1
>
> 
>
> The candidate for Mesos 0.22.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz
>
> The tag to be voted on is 0.22.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1072
>
> Please vote on releasing this package as Apache Mesos 0.22.2!
>
> The vote is open until Mon Sep 28 18:00 PDT 2015 and passes if a majority
> of at least 3 +1 PMC votes are cast.
>
> [ ] +1 I tested this package. Release this package as Apache Mesos 0.22.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
> -Adam-
>

Re: [VOTE] Release Apache Mesos 0.22.2 (rc1)

[Adam Bordelon]

I think the github mirror is still behind. It should sync up eventually.
You can always pull from Apache git directly too:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.2-rc1

On Thu, Sep 24, 2015 at 3:17 AM, haosdent  wrote:

> Hi, @Adam. Could you also add a tag 0.22.2-rc1
> <https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.2-rc1>
>  in
> github?
>
> On Thu, Sep 24, 2015 at 4:50 PM, Adam Bordelon  wrote:
>
>> +1 (binding) Tested on CI for CentOS7, Fedora22, and Ubuntu 14.04.
>>
>> On Thu, Sep 24, 2015 at 12:10 AM, Adam Bordelon 
>> wrote:
>>
>> > Hi friends,
>> >
>> > Here's another docker patch release candidate for you! Please vote on
>> > releasing the following candidate as Apache Mesos 0.22.2.
>> >
>> > 0.22.2 is a bug fix release and includes the following:
>> >
>> >
>> 
>> > * [MESOS-2986] - Docker version output is not compatible with Mesos
>> >
>> > 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=0.22.2-rc1
>> >
>> >
>> 
>> >
>> > The candidate for Mesos 0.22.2 release is available at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz
>> >
>> > The tag to be voted on is 0.22.2-rc1:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.2-rc1
>> >
>> > The MD5 checksum of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.md5
>> >
>> > The signature of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.22.2-rc1/mesos-0.22.2.tar.gz.asc
>> >
>> > The PGP key used to sign the release is here:
>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >
>> > The JAR is up in Maven in a staging repository here:
>> > https://repository.apache.org/content/repositories/orgapachemesos-1072
>> >
>> > Please vote on releasing this package as Apache Mesos 0.22.2!
>> >
>> > The vote is open until Mon Sep 28 18:00 PDT 2015 and passes if a
>> majority
>> > of at least 3 +1 PMC votes are cast.
>> >
>> > [ ] +1 I tested this package. Release this package as Apache Mesos
>> 0.22.2
>> > [ ] -1 Do not release this package because ...
>> >
>> > Thanks,
>> > -Adam-
>> >
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

[RESULT][VOTE] Release Apache Mesos 0.24.1 (rc1)

[Adam Bordelon]

Hi all,

The vote for Mesos 0.24.1 (rc1) has passed with the following votes.

+1 (Binding)
--
Vinod Kone
Niklas Nielsen
Adam B

+1 (Non-binding)
--
haosdent
Jörg Schad

There were no 0 or -1 votes.

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

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=0.24.1

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

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

Thanks,
-Adam-

On Thu, Sep 24, 2015 at 3:07 AM, Jörg Schad  wrote:

> +1 (non-binding) Ubuntu 14.04.3 LTS with sudo make check including docker
> tests.
>
> On Wed, Sep 23, 2015 at 10:41 PM, Adam Bordelon 
> wrote:
>
> > +1 (binding) Tested on CI for CentOS7, Fedora22, and Ubuntu 14.04.
> >
> > On Tue, Sep 22, 2015 at 1:41 PM, Niklas Nielsen 
> > wrote:
> >
> >> +1 (binding)
> >>
> >> On 21 September 2015 at 11:46, Vinod Kone  wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> Tested on CI for CentOS5 and CentOS6.
> >>>
> >>> On Fri, Sep 18, 2015 at 6:21 PM, Adam Bordelon 
> >>> wrote:
> >>>
> >>>> Hi friends,
> >>>>
> >>>> Please vote on releasing the following candidate as Apache Mesos
> 0.24.1.
> >>>>
> >>>> 0.24.1 includes the following:
> >>>>
> >>>>
> 
> >>>> * [MESOS-2986] - Docker version output is not compatible with Mesos
> >>>> * [MESOS-3136] - COMMAND health checks with Marathon 0.10.0 are broken
> >>>>
> >>>> 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=0.24.1-rc1
> >>>>
> >>>>
> 
> >>>>
> >>>> The candidate for Mesos 0.24.1 release is available at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz
> >>>>
> >>>> The tag to be voted on is 0.24.1-rc1:
> >>>>
> >>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.1-rc1
> >>>>
> >>>> The MD5 checksum of the tarball can be found at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz.md5
> >>>>
> >>>> The signature of the tarball can be found at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.1-rc1/mesos-0.24.1.tar.gz.asc
> >>>>
> >>>> The PGP key used to sign the release is here:
> >>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>>>
> >>>> The JAR is up in Maven in a staging repository here:
> >>>>
> https://repository.apache.org/content/repositories/orgapachemesos-1068
> >>>>
> >>>> Please vote on releasing this package as Apache Mesos 0.24.1!
> >>>>
> >>>> The vote is open until Wed Sep 23 18:00 PDT 2015 and passes if a
> >>>> majority
> >>>> of at least 3 +1 PMC votes are cast.
> >>>>
> >>>> [ ] +1 I tested this package. Release it as Apache Mesos 0.24.1
> >>>> [ ] -1 Do not release this package because ...
> >>>>
> >>>> Thanks,
> >>>> -Adam-
> >>>>
> >>>
> >>>
> >>
> >
>

[VOTE] Release Apache Mesos 0.21.2 (rc1)

[Adam Bordelon]

Hi friends,

Here's a candidate for the last of the docker patch releases
(0.21.x-0.24.x).
Please vote on releasing the following candidate as Apache Mesos 0.21.2.

0.21.2 is a bug fix release and includes the following:

* [MESOS-2986] - Docker version output is not compatible with Mesos

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=0.21.2-rc1


The candidate for Mesos 0.21.2 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz

The tag to be voted on is 0.21.2-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.21.2-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1074

Please vote on releasing this package as Apache Mesos 0.21.2!

The vote is open until Tue Sep 29 18:00 PDT 2015 and passes if a majority
of at least 3 +1 PMC votes are cast.

[ ] +1 I tested this package. Release this package as Apache Mesos 0.21.2
[ ] -1 Do not release this package because ...

Thanks,
-Adam-

Re: [VOTE] Release Apache Mesos 0.21.2 (rc1)

[Adam Bordelon]

+1 (binding) Tested on CI for CentOS7 and Ubuntu 14.04.

On Thu, Sep 24, 2015 at 5:44 PM, Adam Bordelon  wrote:

> Hi friends,
>
> Here's a candidate for the last of the docker patch releases
> (0.21.x-0.24.x).
> Please vote on releasing the following candidate as Apache Mesos 0.21.2.
>
> 0.21.2 is a bug fix release and includes the following:
>
> 
> * [MESOS-2986] - Docker version output is not compatible with Mesos
>
> 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=0.21.2-rc1
>
> 
>
> The candidate for Mesos 0.21.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz
>
> The tag to be voted on is 0.21.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.21.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.21.2-rc1/mesos-0.21.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1074
>
> Please vote on releasing this package as Apache Mesos 0.21.2!
>
> The vote is open until Tue Sep 29 18:00 PDT 2015 and passes if a majority
> of at least 3 +1 PMC votes are cast.
>
> [ ] +1 I tested this package. Release this package as Apache Mesos 0.21.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
> -Adam-
>

[RESULT][VOTE] Release Apache Mesos 0.23.1 (rc1)

[Adam Bordelon]

Hi friends,

The vote for Mesos 0.23.1 (rc1) has passed with the following votes.

+1 (Binding)
--
Adam B
Vinod Kone
Niklas Nielsen
Brenden Matthews

+1 (Non-binding)
--
haosdent
Alexander Rojas

There were no 0 or -1 votes.

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

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=0.23.1

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

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

Thanks,
-Adam-

On Thu, Sep 24, 2015 at 4:13 PM, Brenden Matthews 
wrote:

> +1 (binding)
>
> On Thu, Sep 24, 2015 at 3:21 PM, Niklas Nielsen 
> wrote:
>
> > +1 (binding)
> >
> > Tested on centos7 and ubuntu 14.04
> >
> > On 24 September 2015 at 07:53, Alexander Rojas 
> > wrote:
> >
> >> +1 (non binding)
> >>
> >> Tested Ubuntu 14.04, OSX
> >>
> >> > On 22 Sep 2015, at 03:06, Adam Bordelon  wrote:
> >> >
> >> > Hi friends,
> >> >
> >> > Please vote on releasing the following candidate as Apache Mesos
> 0.23.1.
> >> >
> >> > 0.23.1 is a bug fix release and includes the following:
> >> >
> >>
> 
> >> > * [MESOS-2986] - Docker version output is not compatible with Mesos
> >> > * [MESOS-3136] - COMMAND health checks with Marathon 0.10.0 are broken
> >> >
> >> > 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=0.23.1-rc1
> >> <
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.1-rc1
> >> >
> >> >
> >>
> 
> >> >
> >> > The candidate for Mesos 0.23.1 release is available at:
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz
> >> <
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz
> >> >
> >> >
> >> > The tag to be voted on is 0.23.1-rc1:
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.1-rc1
> >> <
> >>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.1-rc1
> >> >
> >> >
> >> > The MD5 checksum of the tarball can be found at:
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.md5
> >> <
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.md5
> >> >
> >> >
> >> > The signature of the tarball can be found at:
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.asc
> >> <
> >>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.1-rc1/mesos-0.23.1.tar.gz.asc
> >> >
> >> >
> >> > The PGP key used to sign the release is here:
> >> > https://dist.apache.org/repos/dist/release/mesos/KEYS <
> >> https://dist.apache.org/repos/dist/release/mesos/KEYS>
> >> >
> >> > The JAR is up in Maven in a staging repository here:
> >> >
> https://repository.apache.org/content/repositories/orgapachemesos-1070
> >> <https://repository.apache.org/content/repositories/orgapachemesos-1070
> >
> >> >
> >> > Please vote on releasing this package as Apache Mesos 0.23.1!
> >> >
> >> > The vote is open until Thu Sep 24 18:00 PDT 2015 and passes if a
> >> majority of at least 3 +1 PMC votes are cast.
> >> >
> >> > [ ] +1 I tested this package. Release it as Apache Mesos 0.24.1
> >> > [ ] -1 Do not release this package because ...
> >> >
> >> > Thanks,
> >> > -Adam-
> >>
> >>
> >
>

[RESULT][VOTE] Release Apache Mesos 0.22.2 (rc1)

[Adam Bordelon]

Hi all,

The vote for Mesos 0.22.2 (rc1) has passed with the following votes.

+1 (Binding)
--
Adam B
Brenden Matthews
Benjamin Mahler

+1 (Non-binding)
--
haosdent

There were no 0 or -1 votes.

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

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=0.22.2

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

The website (http://mesos.apache.org) already has the download link.

Thanks,
-Adam-

Re: Hadoop on Mesos Memory Configuration Question

[Adam Bordelon]

Mesos will take the resources from each slave (total-1GB) and offer that to
the various frameworks registered on your cluster. If Hadoop is the only
framework, it will get offered all of the resources. If there are other
frameworks running, Mesos will offer resources to the framework furthest
below its fair share, to try to maintain Dominant Resource Fairness (see
the DRF paper). It is up to the Hadoop framework scheduler to decide how
much of each offer to use to launch its tasks (TaskTrackers/NodeManagers).
Are you using Hadoop1 framework: https://github.com/mesos/hadoop
Or the Hadoop2/YARN framework: https://github.com/apache/incubator-myriad

On Thu, Oct 1, 2015 at 6:26 PM, Ajit Jagdale  wrote:

> Hi all,
>
> I'm new to Mesos and to using Hadoop over Mesos.  I've been trying to
> determine if Mesos memory configurations are affecting the memory that I
> allocate to Hadoop mappers and reducers (in Hadoop's mapped-site.xml
> file).  When I set values to the mappers, something seems to interfere with
> allocating that memory.
>
> Cluster setup:
> - 1 master node and 6 slave nodes
> - There is no /etc/mesos-slave/resource file, so memory is configured by
> Mesos.  My understanding of this is that since there are no explicit memory
> settings on each slave node, Mesos is giving the asking application
> (Hadoop) all of the available memory minus 1GB for running the OS.
>
> But there still must be some mesos memory configuration somewhere, right?
> Something that knows how much a slice of memory is.  I'm not sure if I know
> where that is.
>
> Any suggestions of how mesos' process of memory allocation could be
> affecting how Hadoop affects memory allocation would be appreciated.
>
> Thanks,
> Ajit
>

[RESULT][VOTE] Release Apache Mesos 0.21.2 (rc1)

[Adam Bordelon]

Hi all,

The vote for Mesos 0.21.2 (rc1) has passed with the following votes.

+1 (Binding)
--
Adam B
Vinod Kone
Michael Park
Niklas Nielsen

There were no 0 or -1 votes.

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

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=0.21.2

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

The website (http://mesos.apache.org) already has the archives download
link, which should be active soon.

Thanks,
-Adam-

Re: Securing executors

[Adam Bordelon]

Paul, yes encryption is a possibility since Mesos 0.23. See
http://mesos.apache.org/documentation/latest/mesos-ssl/
I believe you can also select which listener port you want to use by
specifying LIBPROCESS_PORT in the executor's environment.

On Tue, Oct 6, 2015 at 6:59 AM, Paul Bell  wrote:

> Thanks, Alexander; I will check out the vid.
>
> I kind of assumed that this port was used for exactly the purpose you
> mention.
>
> Is TLS a possibility here?
>
> -Paul
>
> On Tue, Oct 6, 2015 at 8:15 AM, Alexander Rojas 
> wrote:
>
>> Hi Paul,
>>
>> I can refer you to the talk given by Adam Bordelon at MesosCon
>> https://www.youtube.com/watch?v=G3sn1OLYDOE
>>
>> If you want to the short answer, the solution is to put a firewall around
>> your cluster.
>>
>> On a closer look on the port, it is the one used for message passing
>> between the mesas-docker-executor and other mesos components.
>>
>>
>> On 05 Oct 2015, at 19:04, Paul Bell  wrote:
>>
>> Hi All,
>>
>> I am running an nmap port scan on a Mesos agent node and noticed nmap
>> reporting an open TCP port at 50577.
>>
>> Poking around some, I discovered exactly 5 mesos-docker-executor
>> processes, one for each of my 5 Docker containers, and each with an open
>> listen port:
>>
>> root 14131  3617  0 10:39 ?00:00:17 mesos-docker-executor
>> --container=mesos-20151002-172703-2450482247-5050-3014-S0.5563c65a-e33e-4287-8ce4-b2aa8116aa95
>> --docker=/usr/local/ecxmcc/weaveShim --help=false
>> --mapped_directory=/mnt/mesos/sandbox
>> --sandbox_directory=/tmp/mesos/slaves/20151002-172703-2450482247-5050-3014-S0/frameworks/20151002-172703-2450482247-5050-3014-/executors/postgres.ea2954fd-6b6e-11e5-8bef-56847afe9799/runs/5563c65a-e33e-4287-8ce4-b2aa8116aa95
>> --stop_timeout=15secs
>>
>> I suppose that all of this is unsurprising. But I know of at least one
>> big customer who will without delay run Nmap or Nessus against my clustered
>> deployment.
>>
>> So I am wondering what the best practices approach is to securing these
>> open ports.
>>
>> Thanks for your help.
>>
>> -Paul
>>
>>
>>
>>
>>
>

Re: upgrade from 0.24.1 to 0.25

[Adam Bordelon]

> When restartng the masters, should they be restarted gradually (restart a
master, wait 30 seconds, restart the next)?
Craig, ideally you should roll the masters one at a time (maintain a
--quorum of masters up at all times), providing enough time for a new
master to recover the replicated log and be ready for a failover. This
reduces downtime and guarantees a continuous connection to
frameworks/agents. If you restart all the masters at once, there's a period
when they're all inaccessible, and you don't maintain quorum.

On Tue, Oct 13, 2015 at 9:34 AM, craig w  wrote:

> I have not tried to upgrade to 0.25.0 yet. I'm hoping to try the upgrade
> this week. We're currently on mesos 0.24.1 and marathon 0.11.0 (just
> upgraded this today).
>
> I'll give the upgrade to 0.25.0 a shot in a test environment, in the
> meantime if you perform an experiment I'd be interested in your findings.
>
> Thanks,
> Craig
>
> On Tue, Oct 13, 2015 at 12:25 PM, Niklas Nielsen 
> wrote:
>
>> Hi Craig,
>>
>> That should definitely not happen; did you try to upgrade to 0.25.0
>> already? If not, we can try to run an upgrade experiment with that marathon
>> version.
>>
>> Niklas
>>
>> On 13 October 2015 at 02:39, craig w  wrote:
>>
>>> When upgrading from 0.23.0 to 0.24.1, I installed the new binaries and
>>> restarted the masters (all at once), then restarted all of the slaves.
>>>
>>> I then observed all of the tasks that were running (via Marathon 0.10.x)
>>> were restarted. I had expected "no downtime" or restarts, did I
>>> misunderstand the upgrade instructions or did I perhaps do something
>>> incorrectly?
>>>
>>> When restartng the masters, should they be restarted gradually (restart
>>> a master, wait 30 seconds, restart the next)?
>>>
>>> I'm looking to upgrade from 0.24.1 to 0.25.0 but want to avoid having
>>> all of the tasks restart again.
>>>
>>> Thanks,
>>> Craig
>>>
>>
>>
>
>
> --
>
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links
>
>

Re: Apache Mesos Community Sync

[Adam Bordelon]

It's been a while since our last community sync, and tomorrow, Thursday Nov
5th shows up on my calendar as a 3pm Twitter-hosted meeting, since those
have traditionally been "Monthly on the first Thursday". After this, the
other meetings (third Thursday, or every other week?) can alternate between
9pm/9am. Let's get these on the calendar officially.

Vinod, are you/Twitter still planning to host the community sync tomorrow?

On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon  wrote:

> We'll have the next community sync this Thursday (Oct. 15th) from 9-10am
> Pacific.
>
> Please add items to the agenda
> <https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#>
> .
>
> We will use Hangouts on Air again. We will post the video stream link
> shortly before the meeting, and only active participants (especially people
> on the agenda) should join the actual hangout. Others can watch the video
> stream and ask brief questions on #mesos on IRC. If you have something
> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
> into the hangout.
>
> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
> reception on the 2nd floor.
>
>
> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>
>> Got it. Thank you.
>>
>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>> wrote:
>>
>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is still
>> not
>> > available. And here is the link for meeting agenda/notes:
>> >
>> >
>> >
>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>> >
>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>> >
>> > > Do today have community sync?
>> > >
>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon 
>> > > wrote:
>> > >
>> > > > Today's community sync video/audio is archived at:
>> > > > http://youtu.be/ZQT6-fw8Ito
>> > > > The meeting agenda/notes are available at:
>> > > >
>> > > >
>> > >
>> >
>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>> > > >
>> > > > For convenience, today's notes are reproduced below:
>> > > >
>> > > >-
>> > > >
>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>> > > >-
>> > > >
>> > > >   What’s the plan for how many releases we want to support?
>> BenH:
>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x) for
>> > > > which we will
>> > > >   do patch fixes
>> > > >   Neil: Or support an LTS version + recent releases
>> > > >   -
>> > > >
>> > > >   Separate Release Manager for backports? Joris and MPark will
>> RM
>> > for
>> > > >   these patch releases, with Adam shepherding. In general,
>> > > patch/point
>> > > >   releases don’t need to be managed by the same person who did
>> the
>> > > > original
>> > > >   release.
>> > > >   -
>> > > >
>> > > >   Need some guidelines (on the website) for what is a
>> > > >   backport-able/critical patch.
>> > > >   -
>> > > >
>> > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
>> releases,
>> > > >   guidelines for critical patches, RM roles/responsibilities
>> > > >   -
>> > > >
>> > > >0.25.0 Release Planning[Joris]: Dashboard
>> > > ><
>> > > >
>> > >
>> >
>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
>> > > > >
>> > > >-
>> > > >
>> > > >   Planning a triage meeting for Friday, hope to cut 0.25.0-rc1
>> by
>> > > Sept.
>> > > >   23rd.
>> > > >   -
>> > > >
>> > > >MesosCon EU [Adam]: Schedule announced!
>> > > > http://mesosconeu2015.sched.org/
>> > > >-
>> > > >
>> > > >   Register! Attend! Meet cool people! Learn awesome things!
>> > > >   -
>> > > >
>> > > >   Want to grow developer commun

Re: Apache Mesos Community Sync

[Adam Bordelon]

Sounds great! Please join us at Mesosphere HQ, 88 Stevenson St., SF at 3pm
Pacific tomorrow.
We will use youtube-onair again, links to be posted to IRC/email shortly
before the meeting.

Please add agenda items:
https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#heading=h.za1f9dpxisdr

On Wed, Nov 4, 2015 at 4:25 PM, Jie Yu  wrote:

> Adam, since most of the Twitter folks are OOO this week. I chatted with
> Artem/Vinod. we think it makes sense to host the sync at Mesosphere
> tomorrow.
>
> - Jie
>
> On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon  wrote:
>
>> It's been a while since our last community sync, and tomorrow, Thursday
>> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting, since
>> those have traditionally been "Monthly on the first Thursday". After
>> this, the other meetings (third Thursday, or every other week?) can
>> alternate between 9pm/9am. Let's get these on the calendar officially.
>>
>> Vinod, are you/Twitter still planning to host the community sync
>> tomorrow?
>>
>> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon 
>> wrote:
>>
>>> We'll have the next community sync this Thursday (Oct. 15th) from
>>> 9-10am Pacific.
>>>
>>> Please add items to the agenda
>>> <https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#>
>>> .
>>>
>>>
>>> We will use Hangouts on Air again. We will post the video stream link
>>> shortly before the meeting, and only active participants (especially people
>>> on the agenda) should join the actual hangout. Others can watch the video
>>> stream and ask brief questions on #mesos on IRC. If you have something
>>> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
>>> into the hangout.
>>>
>>> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
>>> reception on the 2nd floor.
>>>
>>>
>>> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>>>
>>>> Got it. Thank you.
>>>>
>>>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>>>> wrote:
>>>>
>>>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is
>>>> still not
>>>> > available. And here is the link for meeting agenda/notes:
>>>> >
>>>> >
>>>> >
>>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>>> >
>>>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>>>> >
>>>> > > Do today have community sync?
>>>> > >
>>>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon >>> >
>>>> > > wrote:
>>>> > >
>>>> > > > Today's community sync video/audio is archived at:
>>>> > > > http://youtu.be/ZQT6-fw8Ito
>>>> > > > The meeting agenda/notes are available at:
>>>> > > >
>>>> > > >
>>>> > >
>>>> >
>>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>>> > > >
>>>> > > > For convenience, today's notes are reproduced below:
>>>> > > >
>>>> > > >-
>>>> > > >
>>>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>>>> > > >-
>>>> > > >
>>>> > > >   What’s the plan for how many releases we want to support?
>>>> BenH:
>>>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x)
>>>> for
>>>> > > > which we will
>>>> > > >   do patch fixes
>>>> > > >   Neil: Or support an LTS version + recent releases
>>>> > > >   -
>>>> > > >
>>>> > > >   Separate Release Manager for backports? Joris and MPark
>>>> will RM
>>>> > for
>>>> > > >   these patch releases, with Adam shepherding. In general,
>>>> > > patch/point
>>>> > > >   releases don’t need to be managed by the same person who
>>>> did the
>>>> > > > original
>>>> > > >   release.
>>>> > > >   -
>>&

Re: Welcome Kapil as Mesos committer and PMC member!

[Adam Bordelon]

Welcome, Kapil! Well-deserved.

On Thu, Nov 5, 2015 at 2:07 AM, haosdent  wrote:

> Congratulations!
>
> On Thu, Nov 5, 2015 at 6:02 PM, Till Toenshoff  wrote:
>
>> I'm happy to announce that Kapil Arya has been voted a Mesos committer
>> and PMC member!
>>
>> Welcome Kapil, and thanks for all of your great contributions to the
>> project so far!
>>
>> Looking forward to lots more of your contributions!
>>
>> Thanks
>> Till
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Apache Mesos Community Sync

[Adam Bordelon]

Sorry for the late link, but you can see the youtube stream (and
after-the-fact video) at: http://youtu.be/rJyT8xDzhcA

We also have a hangout link for those with agenda items, or those who have
lengthy things to discuss (ask if you need the link). For brief questions,
you can add them to the agenda or ask in IRC and I will relay them for you.

On Wed, Nov 4, 2015 at 4:42 PM, Adam Bordelon  wrote:

> Sounds great! Please join us at Mesosphere HQ, 88 Stevenson St., SF at 3pm
> Pacific tomorrow.
> We will use youtube-onair again, links to be posted to IRC/email shortly
> before the meeting.
>
> Please add agenda items:
>
> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#heading=h.za1f9dpxisdr
>
> On Wed, Nov 4, 2015 at 4:25 PM, Jie Yu  wrote:
>
>> Adam, since most of the Twitter folks are OOO this week. I chatted with
>> Artem/Vinod. we think it makes sense to host the sync at Mesosphere
>> tomorrow.
>>
>> - Jie
>>
>> On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon  wrote:
>>
>>> It's been a while since our last community sync, and tomorrow, Thursday
>>> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting, since
>>> those have traditionally been "Monthly on the first Thursday". After
>>> this, the other meetings (third Thursday, or every other week?) can
>>> alternate between 9pm/9am. Let's get these on the calendar officially.
>>>
>>> Vinod, are you/Twitter still planning to host the community sync
>>> tomorrow?
>>>
>>> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon 
>>> wrote:
>>>
>>>> We'll have the next community sync this Thursday (Oct. 15th) from
>>>> 9-10am Pacific.
>>>>
>>>> Please add items to the agenda
>>>> <https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#>
>>>> .
>>>>
>>>>
>>>> We will use Hangouts on Air again. We will post the video stream link
>>>> shortly before the meeting, and only active participants (especially people
>>>> on the agenda) should join the actual hangout. Others can watch the video
>>>> stream and ask brief questions on #mesos on IRC. If you have something
>>>> lengthier to discuss, put it on the agenda and ping us on email/IRC to get
>>>> into the hangout.
>>>>
>>>> To join in person, come to Mesosphere HQ at 88 Stevenson St and see
>>>> reception on the 2nd floor.
>>>>
>>>>
>>>> On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:
>>>>
>>>>> Got it. Thank you.
>>>>>
>>>>> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
>>>>> wrote:
>>>>>
>>>>> > Yes, community sync is at 3 pm PST today afternoon. Video Link is
>>>>> still not
>>>>> > available. And here is the link for meeting agenda/notes:
>>>>> >
>>>>> >
>>>>> >
>>>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>>>> >
>>>>> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
>>>>> >
>>>>> > > Do today have community sync?
>>>>> > >
>>>>> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon <
>>>>> a...@mesosphere.io>
>>>>> > > wrote:
>>>>> > >
>>>>> > > > Today's community sync video/audio is archived at:
>>>>> > > > http://youtu.be/ZQT6-fw8Ito
>>>>> > > > The meeting agenda/notes are available at:
>>>>> > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
>>>>> > > >
>>>>> > > > For convenience, today's notes are reproduced below:
>>>>> > > >
>>>>> > > >-
>>>>> > > >
>>>>> > > >0.21.2-0.24.1 Patch Releases [Adam]
>>>>> > > >-
>>>>> > > >
>>>>> > > >   What’s the plan for how many releases we want to support?
>>>>> BenH:
>>>>> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x)
>>>>> for
>

Re: Upgrade 0.22.1 --> 0.25.0

[Adam Bordelon]

Please do not skip versions during upgrades. We have been using a
two-version deprecation cycle, so a protobuf field that existed in 0.22.1
may no longer exist in 0.24.x, meaning that a direct live upgrade could
cause masters and agents to stop communicating with each other. We only
guarantee live upgrades from one version to the next minor version (e.g.
0.22.x->0.23.x), so the recommended procedure is to follow the linked
upgrade guide to upgrade the entire cluster (even the libmesos for
schedulers/executors) to the next version, then repeat the procedure to
upgrade the entire cluster to the following version and so on.
The usual process is to upgrade masters first, then agents, then schedulers
and custom executors.
There may be other caveats listed in the upgrades guide that indicate
deprecated/removed endpoints, formatting/behavior changes, etc.

Now that we've moved to a more monthly release cycle, we will be extending
our deprecation cycle to ~6months/versions, so that you could skip versions
in the future. Once we reach 1.0, we'll have stronger guarantees about
upgrading minor versions within 1.x.

On Wed, Dec 9, 2015 at 7:39 AM, tommy xiao  wrote:

> Hi Alex,
>
> I think you need review the mesos upgrade docs.
>
> http://mesos.apache.org/documentation/latest/upgrades/
>
>
>
> 2015-12-09 23:04 GMT+08:00 :
>
>> Hi All!
>>
>> We have running cluster with mesos 0.22.1 and marathon 0.8.2 running on
>> it.
>> Is it safe to upgrade directly 0.22.1 --> 0.25.0 without installing
>> intermediate versions?
>>
>> How i can perform rollback if something went wrong? Would installing
>> previous versions just do the job?
>>
>> --
>>  Alex Griazin
>>
>
>
>
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com
>

Re: Role-related configuration in Mesos

[Adam Bordelon]

First off, if we're going to have a /reservations endpoint, we should
follow the same PUT+DELETE pattern for reserve+unreserve, instead of
POST+PUT. And we should consider converting /create and /destroy to
PUT+DELETE verbs on a /volumes endpoint.

Secondly, we're going to have to support the previous endpoints
through a deprecation cycle (~6mo), so there's no rush to get those
changes in at the same time as or before dynamic weights.

Finally, it seems like the only real difference between the two
proposals is whether (1) /roles will be the catch-all "show me
everything about each role" endpoint that admins/users will request
when they want to see the current state of their
reservations/quota/weights(/volumes?), or (2) each endpoint with
create/update (PUT/POST) and DELETE actions will also have a GET
action that lists the current state of quotas or weights or whatever,
and /roles can (continue to) show whatever subset of information it
wants.

In the long-run, I like the idea of consistency among these types of
endpoints, but for the near-term scope of dynamic weights, I think you
can leave the other endpoints alone (including /roles) and just
implement the PUT/POST+DELETE for /weights to create/update+delete
weight configurations. Since weights are already displayed in /roles,
you can leave them there and not worry about creating a GET for
/weights. That's the least amount of work/disruption you have to do to
deliver the feature/functionality, includes no wasted work no matter
whether we go with your proposal 1 or 2 in the long run.
On that note, we should create a JIRA Epic for defining a proper
RESTful API for these actions and migrating all relevant endpoints to
the new model.

Cheers,
-Adam-

P.S. Seems like RESTful APIs prefer plural nouns over singular, so it
would be /weights instead of /weight.

On Wed, Dec 16, 2015 at 4:02 AM, Yongqiao Wang  wrote:
> Hi guys,
>
> Currently, Mesos uses the following ways to configure role-related objects:
> 1. For dynamic reserve resources for a role, /reserve endpoint is used to
> reserve, another /unreserve endpoint is used to unreserve, maybe the third
> endpoint should be added to show resource reservation of a role later due to
> someone has issue a requirement of this.
>
> 2. For configuring quota for a role, only one endpoint /quota is provided to
> set/remove/show quota information.
>
> 3. For role information, /roles endpoint is only provided to show role
> information(contains role name, weight and the registered frameworks and
> their used resources) that master is configured with (specified by --roles
> when Mesos master startup), and the configured roles do not be changed by
> this endpoint at runtime(without restart Mesos master). And current there
> are two proposals in progress to support re-configure roles at runtime:
> - Dynamic Roles(MESOS-3177): roles are stored in the registry and
> added/deleted/removed/shown via /roles HTTP endpoints with the authorized
> principles.
> - Implicit Roles(MESOS-3988): any role will be allowed, subject to the
> ACL/authorization system.
>
> After having a discussion, we all prefer to implement Implicit Roles rather
> than Dynamic Roles, but dynamic weight is out scope of Implicit Roles, so a
> new project will need be issued for dynamic weight, and like quota, a new
> endpoint(such as /weight) will be added to update weight of a role at
> runtime.
>
> For above design and implementation, they are all different. In order to
> improve the user experience, some enhancements should be done for the same
> behaviours between above endpoints. I have two proposals as below:
>
> Proposals 1, using /roles endpoint to centralizely show all roles
> information and using other endpoints(/weight,/quota,/reservation) to only
> set the role-related configuration.
> - Implement Implicit Roles to support dynamically implicitly add/remove role
> at runtime. and enhance /roles endpoint to centralizely show all role
> information which contains role name, weight, resource reservation,
> quota,etc.
> - For reservation, merge /reserve and /unreserve together, end user can use
> one endpoint /reservation(should better be a noun for a Restful endpoint) to
> reserve(POST method) and unreserve(PUT method) resource, and does not
> support to show reservation with this endpoint;
> - For setting quota, end user can only use /quota endpoint to set and remove
> quota, and does not support to show quota with this endpoint;
> - For dynamic weight, add a new endpoint /weight, end user can use to update
> weight of a role, and does not support to show weights with this endpoint.
>
>
> Proposals 2, keep the old behaviour of /roles endpoint and using other
> endpoints(/weight,/quota,/reservation) to set and show the role-related
> configuration.
> - Implement Implicit Roles to support dynamic implicitly configure role at
> runtime. and keep the old behaviour of /roles to only show role information
> which contains role name, weight and the

Re: Mesos masters and zookeeper running together?

[Adam Bordelon]

If you're only using ZK for Mesos, then it should be fine to have it
on the same nodes as the Mesos masters, since Mesos only uses ZK for
leader election, and not any other metadata storage. Marathon and
other services, however, use ZK more heavily, and if you're seeing
significant ZK load, it would be better to put ZK on a separate
cluster. Alternatively, you could have 1 ZK cluster just for Mesos,
co-located with the masters, and a separate ZK cluster (or multiple)
for your other services.

On Thu, Dec 24, 2015 at 9:39 PM, Rodrick Brown  wrote:
> 3x - r3.xlarge  @ 4x vCPU 30GB Mem 1x80GB SSD
>>
>> On Dec 24 2015, at 6:01 pm, craig w  wrote:
>>
>> What specs do you have for the zookeeper servers? Ram, cpu, disk, OS.
>>
>> On Dec 24, 2015 5:13 PM, "Dick Davies"  wrote:
>>
>> zookeeper really wants a dedicated cluster IMO; preferably with SSD
>> under it - if zookeeper
>> starts to run slow then everything else will start to bog down. I've
>> co-hosted it with mesos masters
>> before now for demo purposes etc. but for production it's probably
>> worth choosing dedicated hosts.
>>
>> On 24 December 2015 at 20:36, Rodrick Brown 
>> wrote:
>> > With our design we end up building out a stand alone zookeeper cluster 3
>> > nodes.  Zookeeper seems to be the default dumping ground for many Apache
>> > based products these days. You will eventually see many services and
>> > frameworks require a zk instance for leader election, coordination, Kv
>> > store
>> > etc.. I've seen situations where the masters can become extremely busy
>> > and
>> > cause performance problem with Zk which can be huge issue for mesos.
>> >
>> > Sent from Outlook Mobile
>> >
>> >
>> >
>> >
>> > On Thu, Dec 24, 2015 at 8:01 AM -0800, "Ron Lipke" 
>> > wrote:
>> >
>> >> Hello, I've been working on setting up a mesos cluster for eventual
>> >> production use and I have a question on configuring zookeeper alongside
>> >> the mesos masters.
>> >> Is it best practice to run zookeeper/exhibitor as a separate cluster
>> >> (in
>> >> our case, three nodes) or on the same machines as the mesos masters?  I
>> >> understand the drawbacks of increased cost for compute resources that
>> >> will just be running a single service and most of the reference docs
>> >> have them running together, but just wondering if it's beneficial to
>> >> have them uncoupled.
>> >>
>> >> Thanks in advance for any input.
>> >>
>> >> Ron Lipke
>> >> @neverminding
>> >
>> >
>> > NOTICE TO RECIPIENTS: This communication is confidential and intended
>> > for
>> > the use of the addressee only. If you are not an intended recipient of
>> > this
>> > communication, please delete it immediately and notify the sender by
>> > return
>> > email. Unauthorized reading, dissemination, distribution or copying of
>> > this
>> > communication is prohibited. This communication does not constitute an
>> > offer
>> > to sell or a solicitation of an indication of interest to purchase any
>> > loan,
>> > security or any other financial product or instrument, nor is it an
>> > offer to
>> > sell or a solicitation of an indication of interest to purchase any
>> > products
>> > or services to any persons who are prohibited from receiving such
>> > information under applicable law. The contents of this communication may
>> > not
>> > be accurate or complete and are subject to change without notice. As
>> > such,
>> > Orchard App, Inc. (including its subsidiaries and affiliates, "Orchard")
>> > makes no representation regarding the accuracy or completeness of the
>> > information contained herein. The intended recipient is advised to
>> > consult
>> > its own professional advisors, including those specializing in legal,
>> > tax
>> > and accounting matters. Orchard does not provide legal, tax or
>> > accounting
>> > advice.
>
>
> NOTICE TO RECIPIENTS: This communication is confidential and intended for
> the use of the addressee only. If you are not an intended recipient of this
> communication, please delete it immediately and notify the sender by return
> email. Unauthorized reading, dissemination, distribution or copying of this
> communication is prohibited. This communication does not constitute an offer
> to sell or a solicitation of an indication of interest to purchase any loan,
> security or any other financial product or instrument, nor is it an offer to
> sell or a solicitation of an indication of interest to purchase any products
> or services to any persons who are prohibited from receiving such
> information under applicable law. The contents of this communication may not
> be accurate or complete and are subject to change without notice. As such,
> Orchard App, Inc. (including its subsidiaries and affiliates, "Orchard")
> makes no representation regarding the accuracy or completeness of the
> information contained herein. The intended recipient is advised to consult
> its own professional advisors, including those specializing in legal, tax
> and accounting matters. Orchard does not p

Re: mesos-master v0.26 crashes for quorum 0

[Adam Bordelon]

You should never specify a quorum of 0.
For 1 master, you specify quorum of 1.
For 3 masters, quorum is 2.
For 5 masters, quorum is 3.
For 7 masters, quorum is 4.
The quorum dictates how many masters (log replicas) have to agree on a fact
to win a vote. If you have a quorum of 0, then no masters vote, so nobody
wins. On a related note, you should always have an odd number of masters,
so that the vote is never tied.

I will admit that the master shouldn't crash with --quorum=0; it should
just exit with an error that quorum must be >=1. Want to file a JIRA?

On Tue, Dec 29, 2015 at 3:43 PM, Mehrotra, Ashish 
wrote:

> Hi All,
>
> I am running Centos 7.1, zookeeper version 3.4.7 and Mesos version 0.26.0.
> After starting the zookeeper, when I tried to start to start the
> meson-server with quorum 0 (everything being run on the same machine, not
> as local but distributed set up), the server crashed.
> This happened immediately after the fresh installs.
> When I changed quorum=1, the mesos master ran fine and the slave could get
> connected.
> Then on restarting the mesos master, there was no issue. * The issue was
> seen the very first time only.*
> The error stack is incomprehensible.
>
> Anyone seen this issue previously?
> The error log was —
>
> [root@abc123 build]# ./bin/mesos-master.sh --ip=10.10.10.118
> --work_dir=/var/lib/mesos --zk=zk://10.10.10.118:2181/mesos *--quorum=0*
> I1229 13:41:24.925851  3345 main.cpp:232] Build: 2015-12-29 12:29:36 by
> root
> I1229 13:41:24.925983  3345 main.cpp:234] Version: 0.26.0
> I1229 13:41:24.929131  3345 main.cpp:255] Using 'HierarchicalDRF' allocator
> I1229 13:41:24.953929  3345 leveldb.cpp:176] Opened db in 24.529078ms
> I1229 13:41:24.955523  3345 leveldb.cpp:183] Compacted db in 1.525191ms
> I1229 13:41:24.955688  3345 leveldb.cpp:198] Created db iterator in
> 107413ns
> I1229 13:41:24.955724  3345 leveldb.cpp:204] Seeked to beginning of db in
> 4553ns
> I1229 13:41:24.955737  3345 leveldb.cpp:273] Iterated through 0 keys in
> the db in 224ns
> I1229 13:41:24.956120  3345 replica.cpp:780] Replica recovered with log
> positions 0 -> 0 with 1 holes and 0 unlearned
> I1229 13:41:24.961802  3345 main.cpp:464] Starting Mesos master
> I1229 13:41:24.965438  3345 master.cpp:367] Master
> a38658f7-89c1-4b1f-84f9-5796234b2104 (localhost) started on
> 10.10.10.118:5050
> I1229 13:41:24.965459  3345 master.cpp:369] Flags at startup:
> --allocation_interval="1secs" --allocator="HierarchicalDRF"
> --authenticate="false" --authenticate_slaves="false"
> --authenticators="crammd5" --authorizers="local" --framework_sorter="drf"
> --help="false" --hostname_lookup="true" --initialize_driver_logging="true"
> --ip="10.10.10.118" --log_auto_initialize="true" --logbufsecs="0"
> --logging_level="INFO" --max_slave_ping_timeouts="5" --port="5050"
> --quiet="false" --quorum="0" --recovery_slave_removal_limit="100%"
> --registry="replicated_log" --registry_fetch_timeout="1mins"
> --registry_store_timeout="5secs" --registry_strict="false"
> --root_submissions="true" --slave_ping_timeout="15secs"
> --slave_reregister_timeout="10mins" --user_sorter="drf" --version="false"
> --webui_dir="/home/admin/mesos/build/../src/webui"
> --work_dir="/var/lib/mesos" --zk="zk://10.10.10.118:2181/mesos"
> --zk_session_timeout="10secs"
> I1229 13:41:24.965761  3345 master.cpp:416] Master allowing
> unauthenticated frameworks to register
> I1229 13:41:24.965772  3345 master.cpp:421] Master allowing
> unauthenticated slaves to register
> I1229 13:41:24.965837  3345 master.cpp:458] Using default 'crammd5'
> authenticator
> W1229 13:41:24.965867  3345 authenticator.cpp:513] No credentials
> provided, authentication requests will be refused
> I1229 13:41:24.965881  3345 authenticator.cpp:520] Initializing server SASL
> I1229 13:41:24.966788  3364 log.cpp:238] Attempting to join replica to
> ZooKeeper group
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@712: Client
> environment:zookeeper.version=zookeeper C client 3.4.5
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@716: Client
> environment:host.name=abc.def.com
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@723: Client
> environment:os.name=Linux
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@724: Client
> environment:os.arch=3.10.0-229.el7.x86_64
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@725: Client
> environment:os.version=#1 SMP Fri Mar 6 11:36:42 UTC 2015
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@733: Client
> environment:user.name=root
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@741: Client
> environment:user.home=/root
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@log_env@753: Client
> environment:user.dir=/home/admin/mesos/build
> 2015-12-29 13:41:24,970:3345(0x7f21042f3700):ZOO_INFO@zookeeper_init@786:
> Initiating client connection, host=10.10.10.118:2181 sessionTimeout=1
> watcher=0x7f2110e3f16c sessionI

Re: More filters on /master/tasks enpoint and filters on /master/state

[Adam Bordelon]

See also:
https://issues.apache.org/jira/browse/MESOS-2258 - Enable filtering of task
information in master/state.json
https://issues.apache.org/jira/browse/MESOS-2353 - Improve performance of
the state.json endpoint for large clusters.
https://issues.apache.org/jira/browse/MESOS-2157 - Add /master/slaves and
/master/frameworks/{framework}/tasks/{task} endpoints
https://docs.google.com/document/d/1dU4e8V6CbomWqHae4FnawZdgK131Iu_YN9uRxZ_y-fw/edit#heading=h.s63wu75ck9qy
- Unraveling of the /state.json endpoint

cc: Alexander, MPark

On Mon, Dec 28, 2015 at 6:20 PM, Klaus Ma  wrote:

> +1
>
> It'll also reduce master's workload; but instead of label, I'd like to
> make master simpler: return tasks page by page and let framework/dashboard
> to filter it themself.
>
>
> 
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform Symphony/DCOS Development & Support, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>
> On Tue, Dec 29, 2015 at 6:09 AM, Diogo Gomes  wrote:
>
>> Hi guys, I would like your opinion about a future feature proposal.
>>
>> Currently, we can use HTTP API to list all our tasks running in our
>> cluster using /master/tasks, but you have to list all tasks or limit/offset
>> this list, we cannot filter this. I would like to filter this, using
>> labels, for example. The use case will be to use mesos to fill our load
>> balancer with tasks data.
>>
>>
>> Marathon currently provides something like this, but only for his tasks,
>> using /v2/apps/?label=[key]==[value]
>>
>>
>> Diogo Gomes
>>
>
>

Re: Mesos on OpenShift 3.1

[Adam Bordelon]

Den, the other option is to run Mesos on top of OpenShift, and then launch
a new k8s-mesos instance on top of Mesos. You wouldn't be reusing the
existing k8s installation, but you could get Mesos and K8s to share
resources better.

On Mon, Jan 4, 2016 at 11:54 PM, Den Cowboy  wrote:

> Okay thanks. Some OpenShift expert told me:
> It should be possible to try it yourself, but you'd probably have to
>  roll up your sleeves a bit and add a new compilation target into the
>  openshift binary (an equivalent to openshift start kubernetes kubelet,
>  but for the km binary). If you're interested I could point out some
>  code to copy to get there.
>
> --
> Date: Tue, 5 Jan 2016 11:00:35 +0800
>
> Subject: Re: Mesos on OpenShift 3.1
> From: gyliu...@gmail.com
> To: user@mesos.apache.org
>
> Sorry I forgot the version, but the "km" binary should located in same
> directory as "kubelet", so seems your kubernetes
> v1.1.0-origin-1107-g4c8e6f4 does not include km distribution.
>
> I think that you can post a question to kubernetes slack channel or
> kubernetes mail list to get some help from there.
>
> Thanks,
>
> Guangya
>
> On Mon, Jan 4, 2016 at 11:33 PM, Den Cowboy  wrote:
>
> Hi,
>
> Thanks for your fast reply. Do you remember on which version of OpenShift
> you were working on?
> And which directory it was?
>
> I see kubelet in the /usr/bin/ folder and there is no folder which is
> named km.
> I'm on OpenShift Origin:
> oc v1.1.0.1-1-g2c6ff4b
> kubernetes v1.1.0-origin-1107-g4c8e6f4
>
> --
> Date: Mon, 4 Jan 2016 23:01:58 +0800
> Subject: Re: Mesos on OpenShift 3.1
> From: gyliu...@gmail.com
> To: user@mesos.apache.org
>
>
> Hi Den,
>
> AFAIK, the OpenShift do not include Kubenetes-Mesos distro when I try it
> month ago, but I do not know if it includes Kubenetes-Mesos distro for now.
> You can double check if there is a binary named as "km" which is in same
> directory as "kubelet", if the "km" is there, then you can migrate your
> Kubernetes running on Mesos by following
> https://github.com/kubernetes/kubernetes/blob/master/docs/getting-started-guides/mesos.md;
> otherwise, you cannot.
>
> Thanks,
>
> Guangya
>
>
> On Mon, Jan 4, 2016 at 10:41 PM, Den Cowboy  wrote:
>
> I'm able to install and configure OpenShift 3.1 with ansible.
> I will have an OpenShift environment which is using Docker and Kubernetes.
> So it's easy to build/deploy and host applications using docker images.
>
> But there is a 'new' problem. We received some Docker images which contain
> one product together.
> This product is using Apache Mesos. So it will need it on OpenShift. I
> read it's possible to run Mesos and Kubernetes together.
> Is this also possible after the Kubernetes installation with OpenShift?
>
> Can you give me some hints how to perform this process if it's possible?
>
> Thanks
>
>
>
>

Re: China Mesos Developers Wechat Group

[Adam Bordelon]

Haosdent, I think Apache mail may strip out images, so you'll have to send
a link to the QR image.

On Sun, Feb 7, 2016 at 8:02 AM, haosdent  wrote:

> Hi, our dear Chinese friends. Because some interesting things related to
> China Network, it is a bit difficult to communicated with Google Hangout or
> other tools. Thank to Tommy Xiao. He create a wechat group named
> "mesos开发爱好者". Feel free to scan this QR code and join this group if you
> have a wechat account.
>
> [image: Inline image 1]
> Happy Lunar New Year!
>
> --
> Best Regards,
> Haosdent Huang
>

Re: blog post for 0.27.0 release

[Adam Bordelon]

FYI, Blog post is up now:
http://mesos.apache.org/blog/mesos-0-27-0-released/

On Wed, Feb 3, 2016 at 5:12 AM, haosdent  wrote:

> There is no blog post about 0.27 so far. But you could found more details
> about it in this result email [RESULT][VOTE] Release Apache Mesos 0.27.0
> (rc2) http://search-hadoop.com/m/0Vlr643RFXHE1q62 .
>
> On Wed, Feb 3, 2016 at 7:15 PM, craig w  wrote:
>
>> Will there be a blog post for the 0.27.0 release?
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Safe update of agent attributes

[Adam Bordelon]

Currently, changing any --attributes or --resources requires draining the
agent and killing all running tasks.
See https://issues.apache.org/jira/browse/MESOS-1739
You could do a `mesos-slave --recovery=cleanup` which essentially kills all
the tasks and clears the work_dir; then restart with a `mesos-slave
--attributes=new_attributes`
Note that even adding a new attribute is the kind of change that could
cause a framework scheduler to no longer want its task on that node. For
example, you add "public_ip=true" and now my scheduler no longer wants to
run private tasks there. As such, any attribute change needs to notify all
schedulers of the change.


On Mon, Feb 22, 2016 at 2:01 PM, Marco Massenzio 
wrote:

> IIRC you can avoid the issue by either using a different work_dir for the
> agent, or removing (and, possibly, re-creating) it.
>
> I'm afraid I don't have a running instance of Mesos on this machine and
> can't test it out.
>
> Also (and this is strictly my opinion :) I would consider a change of
> attribute a "material" change for the Agent and I would avoid trying to
> recover state from previous runs; but, again, there may be perfectly
> legitimate cases in which this is desirable.
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Mon, Feb 22, 2016 at 12:11 PM, Zhitao Li  wrote:
>
>> Hi,
>>
>> We recently discovered that updating attributes on Mesos agents is a very
>> risk operation, and has a potential to send agent(s) into a crash loop if
>> not done properly with errors like "Failed to perform recovery:
>> Incompatible slave info detected". This combined with --recovery_timeout
>> made the situation even worse.
>>
>> In our setup, some of the attributes are generated from automated
>> configuration management system, so this opens a possibility that "bad"
>> configuration could be left on the machine and causing big trouble on next
>> agent upgrade, if the USR1 signal was not sent on time.
>>
>> Some questions:
>>
>> 1. Does anyone have a good practice recommended on managing these
>> attributes safely?
>> 2. Has Mesos considered to fallback to old metadata if it detects
>> incompatibility, so agents would keep running with old attributes instead
>> of falling into crash loop?
>>
>> Thanks.
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>

Re: Cleaning up failed tasks in the UI

[Adam Bordelon]

I suspect that after your maintenance operation, Marathon may have
registered with a new frameworkId and launched is own copies of your tasks
(why you see double). However, the old Marathon frameworkId probably has a
failover_timeout of a week, so it will continue to be considered
"registered", but "disconnected".
Check the /frameworks endpoint to see if Mesos thinks you have two
Marathons registered.
If so, you can use the /teardown endpoint to unregister the old one, which
will cause all of its tasks to be killed.

On Wed, Mar 30, 2016 at 4:56 AM, Alberto del Barrio <
alberto.delbarrio.albe...@gmail.com> wrote:

> Hi haosdent,
>
> thanks for your reply. It is actually very weird, first time I see this
> situation in around one year using mesos.
> I am pasting here the truncate output you asked for. It is showing one of
> the tasks with "Failed" state under "Active tasks":
>
> {
> "executor_id": "",
> "framework_id":
> "c857c625-25dc-4650-89b8-de4b597026ed-",
> "id": "pixie.33f85e8f-f03b-11e5-af6c-fa6389efeef1",
> "labels": [
>..
> ],
> "name": "myTask",
> "resources": {
> "cpus": 4.0,
> "disk": 0,
> "mem": 2560.0,
> "ports": "[31679-31679]"
> },
> "slave_id":
> "c857c625-25dc-4650-89b8-de4b597026ed-S878",
> "state": "TASK_FAILED",
> "statuses": [
> {
> "container_status": {
> "network_infos": [
> {
> "ip_address": "10.XX.XX.XX"
> }
> ]
> },
> "state": "TASK_RUNNING",
> "timestamp": 1458657321.16671
> },
> {
> "container_status": {
> "network_infos": [
> {
> "ip_address": "10.XX.XX.XX"
> }
> ]
> },
> "state": "TASK_FAILED",
> "timestamp": 1459329310.13663
> }
> ]
> },
>
>
> t
>
>
> On 03/30/16 13:30, haosdent wrote:
>
> >"Active tasks" with status "Failed"
> A bit wired here. According to my test, it should exists in "Completed
> Tasks". If possible, could you show you /master/state endpoint result. I
> think the frameworks node in state response would be helpful to analyze the
> problem.
>
> On Wed, Mar 30, 2016 at 6:26 PM, Alberto del Barrio <
> alberto.delbarrio.albe...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> after a maintenance carried on in a mesos cluster (0.25) using marathon
>> (0.10) as a only scheduler , I've finished with the double of tasks for
>> each application. But marathon was recognizing only half of them.
>> For getting rid of this orphaned tasks, I've did a "kill PID" of them, so
>> they free up their resources.
>>
>> My problem now is that these tasks I've killed, are still appearing in
>> the mesos UI under "Active tasks" with status "Failed". This is not
>> affecting my system, but I would like to clean them up.
>> Googling I can't find anything.
>> Can someone point me to a solution for cleaning those tasks?
>>
>> Cheers,
>> Alberto.
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>
>
>

Re: Mesos 0.28 SSL in official packages

[Adam Bordelon]

Hi Kamil,

Technically, there are no "official" Apache-built packages for Apache Mesos.

At least once company (Mesosphere) chooses to build and distribute
Mesos packages, but does not currently offer SSL builds. It wouldn't
be hard to add an SSL build to our regular builds, but it hasn't been
requested enough to prioritize it.

cc: Joris, Kapil

On Thu, Apr 7, 2016 at 7:42 AM, haosdent  wrote:
> Hi, ssl didn't enable default. You need compile it by following this doc
> http://mesos.apache.org/documentation/latest/ssl/
>
> On Thu, Apr 7, 2016 at 10:04 PM, Kamil Wokitajtis 
> wrote:
>>
>> This is my first post, so Hi everyone!
>>
>> Is SSL enabled in official packages (CentOS in my case)?
>> I can see libssl in ldd output, but I cannot see libevent.
>> I had to compile mesos from sources to run it over ssl.
>> I would prefer to install it from packages.
>>
>> Regards,
>> Kamil
>
>
>
>
> --
> Best Regards,
> Haosdent Huang

Re: Mesos 0.28 SSL in official packages

[Adam Bordelon]

We've discussed Apache-built/distributed packages before, and nobody
has any objections, but we need somebody to take on the work to get
the package builds setup. I believe Vinod had some thoughts on how to
get started, but any Apache committer (Zameer?) should have access to
builds.apache.org
I think we're all also in favor of improved documentation/website for
the Apache Mesos project, but we need your help for that too. File
JIRAs, submit patches!

On Tue, Apr 12, 2016 at 5:42 AM, June Taylor  wrote:
> I heartily agree on both points. While I've found Mesosphere's documentation
> very helpful, it is often mixed up with the DCOS commercial offering. That
> may be something we're interested in down the road, but right now we are
> trying to stand up a relatively small cluster using straight
> Mesos/Marathon/Chronos, etc., and finding good documentation is very
> challenging due to the overlap with DCOS.
>
> The Apache documentation also, I think, is suffering precisely because
> Mesosphere has been serving up better materials on their own. It's certainly
> useful, but I'm a bit uncomfortable with that arrangement.
>
>
> Thanks,
> June Taylor
> System Administrator, Minnesota Population Center
> University of Minnesota
>
> On Tue, Apr 12, 2016 at 7:04 AM, Paul Bell  wrote:
>>
>> FWIW, I quite agree with Zameer's point.
>>
>> That said, I want to make abundantly clear that in my experience the folks
>> at Mesosphere are wonderfully helpful.
>>
>> But what happens if down the road Mesosphere is acquired or there occurs
>> some other event that could represent, if not a conflict of interest, then
>> simply a different strategic direction?
>>
>> My 2 cents.
>>
>> -Paul
>>
>> On Mon, Apr 11, 2016 at 5:19 PM, Zameer Manji  wrote:
>>>
>>> I have suggested this before and I will suggest it again here.
>>>
>>> I think the Apache Mesos project should build and distribute packages
>>> instead of relying on the generosity of a commercial vendor. The Apache
>>> Aurora project does this already with good success. As a user of Apache
>>> Mesos I don't care about Mesosphere Inc and I feel uncomfortable that the
>>> project is so dependent on its employees.
>>>
>>> Doing this would allow users to contribute packaging fixes directly to
>>> the project, such as enabling SSL.
>>>
>>> On Mon, Apr 11, 2016 at 3:02 AM, Adam Bordelon 
>>> wrote:
>>>>
>>>> Hi Kamil,
>>>>
>>>> Technically, there are no "official" Apache-built packages for Apache
>>>> Mesos.
>>>>
>>>> At least once company (Mesosphere) chooses to build and distribute
>>>> Mesos packages, but does not currently offer SSL builds. It wouldn't
>>>> be hard to add an SSL build to our regular builds, but it hasn't been
>>>> requested enough to prioritize it.
>>>>
>>>> cc: Joris, Kapil
>>>>
>>>> On Thu, Apr 7, 2016 at 7:42 AM, haosdent  wrote:
>>>> > Hi, ssl didn't enable default. You need compile it by following this
>>>> > doc
>>>> > http://mesos.apache.org/documentation/latest/ssl/
>>>> >
>>>> > On Thu, Apr 7, 2016 at 10:04 PM, Kamil Wokitajtis
>>>> > 
>>>> > wrote:
>>>> >>
>>>> >> This is my first post, so Hi everyone!
>>>> >>
>>>> >> Is SSL enabled in official packages (CentOS in my case)?
>>>> >> I can see libssl in ldd output, but I cannot see libevent.
>>>> >> I had to compile mesos from sources to run it over ssl.
>>>> >> I would prefer to install it from packages.
>>>> >>
>>>> >> Regards,
>>>> >> Kamil
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Best Regards,
>>>> > Haosdent Huang
>>>>
>>>> --
>>>> Zameer Manji
>>>>
>>
>

Re: Mesos 0.28 SSL in official packages

[Adam Bordelon]

Mesosphere open-sourced the package-building scripts long ago:
https://github.com/mesosphere/mesos-deb-packaging
The TeamCity configuration, however, is internal-only, but that
wouldn't work for Apache anyway, since Apache doesn't use TeamCity
AFAIK.

On Tue, Apr 12, 2016 at 11:07 AM, Zameer Manji  wrote:
> For the record, I am not a committer on the Apache Mesos project and I do
> not have the time to contribute packaging tools for the project. I think
> existing committers who are Mesosphere employees can kick start this effort
> by asking their employer to contribute the existing tools to the project.
> Then any committer can incorporate creating packages as a step in the
> release process.
>
> On Tue, Apr 12, 2016 at 10:10 AM, Kapil Arya  wrote:
>>
>> At Mesosphere, we are planning to enable SSL into the nightlies starting
>> sometime later this week. The goal is to have both SSL and non-SSL Mesos
>> packages for Mesos 0.29.0 onwards in the Mesosphere deb/rpm repos. I will
>> send out another email as soon as the stuff is ready for the community.
>>
>> Best,
>> Kapil
>>
>> On Tue, Apr 12, 2016 at 12:22 PM, Steven Borrelli 
>> wrote:
>>>
>>> I’d be willing to assist in the effort to have standard packages (and
>>> additional packages for modules like net-modules).
>>>
>>> Steven Borrelli
>>> st...@borrelli.org
>>>
>>>
>>>
>>> > On Apr 12, 2016, at 11:10 AM, Adam Bordelon  wrote:
>>> >
>>> > We've discussed Apache-built/distributed packages before, and nobody
>>> > has any objections, but we need somebody to take on the work to get
>>> > the package builds setup. I believe Vinod had some thoughts on how to
>>> > get started, but any Apache committer (Zameer?) should have access to
>>> > builds.apache.org
>>> > I think we're all also in favor of improved documentation/website for
>>> > the Apache Mesos project, but we need your help for that too. File
>>> > JIRAs, submit patches!
>>> >
>>> > On Tue, Apr 12, 2016 at 5:42 AM, June Taylor  wrote:
>>> >> I heartily agree on both points. While I've found Mesosphere's
>>> >> documentation
>>> >> very helpful, it is often mixed up with the DCOS commercial offering.
>>> >> That
>>> >> may be something we're interested in down the road, but right now we
>>> >> are
>>> >> trying to stand up a relatively small cluster using straight
>>> >> Mesos/Marathon/Chronos, etc., and finding good documentation is very
>>> >> challenging due to the overlap with DCOS.
>>> >>
>>> >> The Apache documentation also, I think, is suffering precisely because
>>> >> Mesosphere has been serving up better materials on their own. It's
>>> >> certainly
>>> >> useful, but I'm a bit uncomfortable with that arrangement.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> June Taylor
>>> >> System Administrator, Minnesota Population Center
>>> >> University of Minnesota
>>> >>
>>> >> On Tue, Apr 12, 2016 at 7:04 AM, Paul Bell  wrote:
>>> >>>
>>> >>> FWIW, I quite agree with Zameer's point.
>>> >>>
>>> >>> That said, I want to make abundantly clear that in my experience the
>>> >>> folks
>>> >>> at Mesosphere are wonderfully helpful.
>>> >>>
>>> >>> But what happens if down the road Mesosphere is acquired or there
>>> >>> occurs
>>> >>> some other event that could represent, if not a conflict of interest,
>>> >>> then
>>> >>> simply a different strategic direction?
>>> >>>
>>> >>> My 2 cents.
>>> >>>
>>> >>> -Paul
>>> >>>
>>> >>> On Mon, Apr 11, 2016 at 5:19 PM, Zameer Manji 
>>> >>> wrote:
>>> >>>>
>>> >>>> I have suggested this before and I will suggest it again here.
>>> >>>>
>>> >>>> I think the Apache Mesos project should build and distribute
>>> >>>> packages
>>> >>>> instead of relying on the generosity of a commercial vendor. The
>>> >>>> Apache
>>> >>>> Aurora project does this already with good success. As 

Re: Mesos Master and Slave on same server?

[Adam Bordelon]

See also my answer to
http://stackoverflow.com/questions/26597521/can-mesos-master-and-slave-nodes-be-deployed-on-the-same-machines


On Wed, Apr 13, 2016 at 12:45 PM, Stefano Bianchi 
wrote:

> I have set an HA cluster.
> 3 mesos slaves with one leader and quorum 2.
> 3 mesos slaves.
> I can easily start tasks from marathon.
> The common way is set the slaves on other machines.
> However if you are running the mesos-slave service also on the master is
> it not a problem.
>
> 2016-04-13 19:24 GMT+02:00 Paul Bell :
>
>> Hi June,
>>
>> In addition to doing what Pradeep suggests, I also now & then run a
>> single node "cluster" that houses mesos-master, mesos-slave, and Marathon.
>>
>> Works fine.
>>
>> Cordially,
>>
>> Paul
>>
>> On Wed, Apr 13, 2016 at 12:36 PM, Pradeep Chhetri <
>> pradeep.chhetr...@gmail.com> wrote:
>>
>>> I would suggest you to run mesos-master and zookeeper and marathon on
>>> same set of hosts (maybe call them as coordinator nodes) and use completely
>>> different set of nodes for mesos slaves. This way you can do the
>>> maintenance of such hosts in a very planned fashion.
>>>
>>> On Wed, Apr 13, 2016 at 4:22 PM, Stefano Bianchi 
>>> wrote:
>>>
 For sure it is possible.
 Simply Mesos-master will the the resources offered by the machine on
 which is running mesos-slave also, transparently.

 2016-04-13 16:34 GMT+02:00 June Taylor :

> All of our node servers are identical hardware. Is it reasonable for
> me to install the Mesos-Master and Mesos-Slave on the same physical
> hardware?
>
> Thanks,
> June Taylor
> System Administrator, Minnesota Population Center
> University of Minnesota
>


>>>
>>>
>>> --
>>> Regards,
>>> Pradeep Chhetri
>>>
>>
>>
>

Re: Mesos Task History

[Adam Bordelon]

Yes, these counters are only kept in-memory, so any time a Mesos master
starts, its counters are initialized to 0.

On Wed, Apr 13, 2016 at 9:38 AM, June Taylor  wrote:

> We have a single master at the moment. Does the task history get cleared
> when the mesos-master restarts?
>
>
> Thanks,
> June Taylor
> System Administrator, Minnesota Population Center
> University of Minnesota
>
> On Wed, Apr 13, 2016 at 11:33 AM, Pradeep Chhetri <
> pradeep.chhetr...@gmail.com> wrote:
>
>> Yes, they get cleaned up whenever the mesos master leader failover
>> happens.
>>
>> On Wed, Apr 13, 2016 at 3:32 PM, June Taylor  wrote:
>>
>>> I am noticing that recently our Completed Tasks and Terminated
>>> Frameworks lists are empty. Where are these stored, and do they get
>>> automatically cleared out at some interval?
>>>
>>> Thanks,
>>> June Taylor
>>> System Administrator, Minnesota Population Center
>>> University of Minnesota
>>>
>>
>>
>>
>> --
>> Regards,
>> Pradeep Chhetri
>>
>
>

Re: Mesos Masters Leader Keeps Fluctuating

[Adam Bordelon]

Having 2 masters (even with a quorum of 2) is no more useful than having a
single master, since if one of your 2 masters goes down you lose quorum,
and your cluster will fail to recover, since it cannot write state changes
to both masters.

Setting the quorum to 1 for a cluster with 2 masters would expose you to
potential split-brain problems, in case of a network partition. You would
then have 2 masters that each think they are the leader, and they would be
unable to reconcile their differences if the partition ends and they
reconnect to each other.

It is intended that you will have an odd number of masters (similar to the
requirement to have an odd number of ZKs), and quorum = ceiling(numMasters
/ 2); so you would have 1 master (quorum=1), 3 masters (quorum=2), or 5
masters (quorum=3).

On Wed, Apr 13, 2016 at 8:44 AM, haosdent  wrote:

> It sounds like an issue in 0.28. I create a ticket
> https://issues.apache.org/jira/browse/MESOS-5207 from this to continue to
>  investigate. If @suruchi you could attach logs of mesos masters and your
> zookeeper configuration, I think it would more helpful for investigating.
>
> On Wed, Apr 13, 2016 at 8:24 PM, Stefano Bianchi 
> wrote:
>
>> Thanks for your reply @haosdent.
>> I destroyed my VM and re build mesos 0.28 with just one master, and now
>> is working.
>> i will try to add another master but for the moment, since on openstack i
>> don't have much resources i need to use that VM as a slave.
>> However in the previous configuration the switch between two masters was
>> ok, just when the master was leading after, more or less 30 seconds, there
>> was that Failed to connect message.
>>
>> 2016-04-13 13:08 GMT+02:00 haosdent :
>>
>>> Hi, @Stefano Could you show conf/zoo.cfg? And how many zookeper nodes
>>> you haved? And "but after a while again Failed to connec"​, how long
>>> the interval here? Is it always "few seconds"?
>>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Mesos Masters Leader Keeps Fluctuating

[Adam Bordelon]

See also http://mesos.apache.org/documentation/latest/operational-guide/

On Wed, Apr 13, 2016 at 2:44 PM, Adam Bordelon  wrote:

> Having 2 masters (even with a quorum of 2) is no more useful than having a
> single master, since if one of your 2 masters goes down you lose quorum,
> and your cluster will fail to recover, since it cannot write state changes
> to both masters.
>
> Setting the quorum to 1 for a cluster with 2 masters would expose you to
> potential split-brain problems, in case of a network partition. You would
> then have 2 masters that each think they are the leader, and they would be
> unable to reconcile their differences if the partition ends and they
> reconnect to each other.
>
> It is intended that you will have an odd number of masters (similar to the
> requirement to have an odd number of ZKs), and quorum = ceiling(numMasters
> / 2); so you would have 1 master (quorum=1), 3 masters (quorum=2), or 5
> masters (quorum=3).
>
> On Wed, Apr 13, 2016 at 8:44 AM, haosdent  wrote:
>
>> It sounds like an issue in 0.28. I create a ticket
>> https://issues.apache.org/jira/browse/MESOS-5207 from this to continue
>> to
>>  investigate. If @suruchi you could attach logs of mesos masters and your
>> zookeeper configuration, I think it would more helpful for investigating.
>>
>> On Wed, Apr 13, 2016 at 8:24 PM, Stefano Bianchi 
>> wrote:
>>
>>> Thanks for your reply @haosdent.
>>> I destroyed my VM and re build mesos 0.28 with just one master, and now
>>> is working.
>>> i will try to add another master but for the moment, since on openstack
>>> i don't have much resources i need to use that VM as a slave.
>>> However in the previous configuration the switch between two masters was
>>> ok, just when the master was leading after, more or less 30 seconds, there
>>> was that Failed to connect message.
>>>
>>> 2016-04-13 13:08 GMT+02:00 haosdent :
>>>
>>>> Hi, @Stefano Could you show conf/zoo.cfg? And how many zookeper nodes
>>>> you haved? And "but after a while again Failed to connec"​, how long
>>>> the interval here? Is it always "few seconds"?
>>>>
>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>

Re: Mesos Masters Leader Keeps Fluctuating

[Adam Bordelon]

You could try attaching them to this thread, but ideally we'd want them
attached to the JIRA that haosdent created:
https://issues.apache.org/jira/browse/MESOS-5207
You may need to create a JIRA account to upload a file. If it still won't
let you, ask dev@ to make you a JIRA contributor.

On Thu, Apr 14, 2016 at 1:50 AM, Stefano Bianchi 
wrote:

> Ok please follow me in this strange story.
> At the beginning i have set 3 mesos master on the same cluster using mesos
> 0.27
> now i deleted one of these 3 mesos 0.27 masters and build a mesos 0.28 to
> joint to the other 2.
> I get the problem i described after 10 seconds i get failed to connect,
> but the election of new one works fine because the new leader is 0.27 which
> is stable.
> How to send to you logs?
>
> 2016-04-13 23:53 GMT+02:00 Adam Bordelon :
>
>> See also http://mesos.apache.org/documentation/latest/operational-guide/
>>
>> On Wed, Apr 13, 2016 at 2:44 PM, Adam Bordelon 
>> wrote:
>>
>>> Having 2 masters (even with a quorum of 2) is no more useful than having
>>> a single master, since if one of your 2 masters goes down you lose quorum,
>>> and your cluster will fail to recover, since it cannot write state changes
>>> to both masters.
>>>
>>> Setting the quorum to 1 for a cluster with 2 masters would expose you to
>>> potential split-brain problems, in case of a network partition. You would
>>> then have 2 masters that each think they are the leader, and they would be
>>> unable to reconcile their differences if the partition ends and they
>>> reconnect to each other.
>>>
>>> It is intended that you will have an odd number of masters (similar to
>>> the requirement to have an odd number of ZKs), and quorum =
>>> ceiling(numMasters / 2); so you would have 1 master (quorum=1), 3 masters
>>> (quorum=2), or 5 masters (quorum=3).
>>>
>>> On Wed, Apr 13, 2016 at 8:44 AM, haosdent  wrote:
>>>
>>>> It sounds like an issue in 0.28. I create a ticket
>>>> https://issues.apache.org/jira/browse/MESOS-5207 from this to continue
>>>> to
>>>>  investigate. If @suruchi you could attach logs of mesos masters and
>>>> your zookeeper configuration, I think it would more helpful for
>>>> investigating.
>>>>
>>>> On Wed, Apr 13, 2016 at 8:24 PM, Stefano Bianchi 
>>>> wrote:
>>>>
>>>>> Thanks for your reply @haosdent.
>>>>> I destroyed my VM and re build mesos 0.28 with just one master, and
>>>>> now is working.
>>>>> i will try to add another master but for the moment, since on
>>>>> openstack i don't have much resources i need to use that VM as a slave.
>>>>> However in the previous configuration the switch between two masters
>>>>> was ok, just when the master was leading after, more or less 30 seconds,
>>>>> there was that Failed to connect message.
>>>>>
>>>>> 2016-04-13 13:08 GMT+02:00 haosdent :
>>>>>
>>>>>> Hi, @Stefano Could you show conf/zoo.cfg? And how many zookeper nodes
>>>>>> you haved? And "but after a while again Failed to connec"​, how long
>>>>>> the interval here? Is it always "few seconds"?
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Haosdent Huang
>>>>
>>>
>>>
>>
>

Re: Mesos Task History

[Adam Bordelon]

You might also want to check out TwoSigma's Satellite:
https://github.com/twosigma/satellite
Sunil's Satellite talk from MesosCon:
https://www.youtube.com/watch?v=yLkc17HFEb8

On Thu, Apr 14, 2016 at 9:16 AM, Dick Davies  wrote:

> We just grab them with collectds mesos plugin and log to Graphite,
> gives us long term trend details.
>
> https://github.com/rayrod2030/collectd-mesos
>
> Haven't used this one but it supposedly does per-task metric collection:
>
> https://github.com/bobrik/collectd-mesos-tasks
>
> On 14 April 2016 at 13:37, June Taylor  wrote:
> > Adam,
> >
> > Is there a way to keep this history?
> >
> >
> > Thanks,
> > June Taylor
> > System Administrator, Minnesota Population Center
> > University of Minnesota
> >
> > On Wed, Apr 13, 2016 at 4:32 PM, Adam Bordelon 
> wrote:
> >>
> >> Yes, these counters are only kept in-memory, so any time a Mesos master
> >> starts, its counters are initialized to 0.
> >>
> >> On Wed, Apr 13, 2016 at 9:38 AM, June Taylor  wrote:
> >>>
> >>> We have a single master at the moment. Does the task history get
> cleared
> >>> when the mesos-master restarts?
> >>>
> >>>
> >>> Thanks,
> >>> June Taylor
> >>> System Administrator, Minnesota Population Center
> >>> University of Minnesota
> >>>
> >>> On Wed, Apr 13, 2016 at 11:33 AM, Pradeep Chhetri
> >>>  wrote:
> >>>>
> >>>> Yes, they get cleaned up whenever the mesos master leader failover
> >>>> happens.
> >>>>
> >>>> On Wed, Apr 13, 2016 at 3:32 PM, June Taylor  wrote:
> >>>>>
> >>>>> I am noticing that recently our Completed Tasks and Terminated
> >>>>> Frameworks lists are empty. Where are these stored, and do they get
> >>>>> automatically cleared out at some interval?
> >>>>>
> >>>>> Thanks,
> >>>>> June Taylor
> >>>>> System Administrator, Minnesota Population Center
> >>>>> University of Minnesota
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Pradeep Chhetri
> >>>
> >>>
> >>
> >
>

Re: setting roles in mesos 0.28

[Adam Bordelon]

Seems like you're trying to start Marathon with multiple Mesos roles
"spark;sparkr;ms;qa", but Marathon may be interpreting this as a single
role that happens to include semi-colons. Mesos does not yet support
multiple roles in a single framework. See
https://issues.apache.org/jira/browse/MESOS-1763
Note that the acceptedResourceRoles feature in Marathon currently only
applies to the "*" (unreserved) role vs. the value of --mesos_role

On Wed, Apr 20, 2016 at 5:19 AM, Rodrick Brown 
wrote:

> On Apr 20 2016, at 1:36 am, Jian Qiu  wrote:
>
>> It is not necessary to configure --role on master. Actually it should
>> work if you configure --default_role='sparkr' on agent and start marathon
>> with --mesos_role=sparkr. Which version of mesos are you using? And could
>> you attach the master log?
>>
>
> This is Marathon 0.15 and Mesos 0.28.1
>
> on my masters I have the following attribute set
> $ cat /etc/marathon/conf/mesos_role
> spark;sparkr;ms;qa
>
> On the slave I have the following set in the agent
> $ cat /etc/mesos-slave/default_role
> sparkr
>
> $ cat /etc/mesos-slave/resources
> cpus:10;mem:10
>
> $ cat attributes
> rack:sparkr
>
> I'm trying to launch a simple task from marathon on this agent with
> following configs
>
> $ cat rstudio-mesos-shuffle-server.marathon.json
> {
>"id": "/mesos/rstudio-shuffle-service",
>"cmd": ". /opt/spark-1.6.1/conf/spark-env.sh .
> /opt/spark-1.6.1/sbin/spark-config.sh && .
> /opt/spark-1.6.1/bin/load-spark-env.sh && env &&
> /opt/spark-1.6.1/bin/spark-class
> org.apache.spark.deploy.mesos.MesosExternalShuffleService 1",
>"cpus": 0.5,
>"mem": 1524,
>"disk": 100,
>"user": "mesos",
>"instances": 1,
>"requirePorts": true,
>"acceptedResourceRoles": ["sparkr"],
>"ports":
>[
>  31338
>],
>"constraints": [
>  [
>"hostname","UNIQUE"
>  ],
>  [
>"rack", "LIKE", "sparkr"
>  ]
>],
>"env": {
>"SPARK_HOME": "/opt/spark-1.6.1",
>"SPARK_SCALA_VERSION": "2.11"
>},
>"healthChecks": [
>  {
>"gracePeriodSeconds": 5,
>"intervalSeconds": 10,
>"maxConsecutiveFailures": 3,
>"portIndex": 0,
>"protocol": "TCP",
>"timeoutSeconds": 5
>  }
>],
>"maxLaunchDelaySeconds": 3,
>"backoffFactor": 1.20,
> "upgradeStrategy": {
>  "minimumHealthCapacity": 0.5,
>  "maximumOverCapacity": 0.5
>}
> }
>
> In the marathon logs this is what I see
>
> 20 12:11:42 prod-mesos-m-3.aws.xxx.com marathon[29617]: [2016-04-20
> 12:11:42,807] INFO Offer ID:
> [50ceafa4-f3c1-4738-a9eb-c5d3bf0ff742-O13166461]. Considered resources with
> roles: [sparkr]. Not all basic resources satisfied: cpu not in offer, disk
> not in offer, mem not in offer
> (mesosphere.mesos.ResourceMatcher$:marathon-akka.actor.default-dispatcher-9)
>
> Thanks.
>
>
>
>> On Wed, Apr 20, 2016 at 11:11 AM, Rodrick Brown 
>> wrote:
>>
>> I'm confused do roles need to be configured on masters and slaves or just
>> slaves?
>> The docs says --roles has been deprecated on mesos-master but doesn't
>> state an alternate method.
>>
>>
>> on my slaves i'm using default_role='sparkr' and in marathon I've added
>> --mesos_role=sparkr however I'm not able to get any tasks to run on this
>> server do I need to set it on the masters also ?
>>
>> Please advise thanks.
>>
>> --RB
>>
>>
>>
>> --
>>
>> *Rodrick Brown* / Systems Engineer
>>
>> +1 917 445 6839 / rodr...@orchardplatform.com
>> 
>>
>> *Orchard Platform*
>>
>> 101 5th Avenue, 4th Floor, New York, NY 10003
>>
>> http://www.orchardplatform.com
>>
>> Orchard Blog  | Marketplace
>> Lending Meetup 
>>
>> *NOTICE TO RECIPIENTS*: This communication is confidential and intended
>> for the use of the addressee only. If you are not an intended recipient of
>> this communication, please delete it immediately and notify the sender by
>> return email. Unauthorized reading, dissemination, distribution or copying
>> of this communication is prohibited. This communication does not constitute
>> an offer to sell or a solicitation of an indication of interest to purchase
>> any loan, security or any other financial product or instrument, nor is it
>> an offer to sell or a solicitation of an indication of interest to purchase
>> any products or services to any persons who are prohibited from receiving
>> such information under applicable law. The contents of this communication
>> may not be accurate or complete and are subject to change without notice.
>> As such, Orchard App, Inc. (including its subsidiaries and affiliates,
>> "Orchard") makes no representation regarding the accuracy or completeness
>> of the information contained herein. The intended recipient is advised to
>> consult its own professional advisors, including those specializing in
>> legal, tax and accounting matters. Orchard does not provide legal, tax or
>> accounting advice.

Re: Mesos Web UI

[Adam Bordelon]

Backported to 0.28.x and 0.27.x. The relevant change/typo wasn't introduced
until 0.27.x, so I left 0.26.x alone.

On Fri, Apr 29, 2016 at 9:57 AM, Vinod Kone  wrote:

> Adam, since you committed this, feel free to backport it to the relevant
> stable branches (26.x, 27.x, 28.x). They will be included in the next patch
> releases.
>
> On Fri, Apr 29, 2016 at 9:31 AM, Gilbert Song 
> wrote:
>
>> Julian, since the fix was after 0.28, could you try it again by applying
>> the patch @haosdent provided, or try with mesos master head?
>>
>> On Fri, Apr 29, 2016 at 8:52 AM, Julian Gonzalez Llorente <
>> jgonza...@medallia.com> wrote:
>>
>>> Hello list,
>>>
>>> I found one little error on the web UI of mesos.
>>> In the "Slaves" tab there are a table with the columns: ID, Host, CPUs,
>>> Mem, Disk, Registered and Re-Registered.
>>> But in the "Offers" tab there is two times Mem. : ID, Framework, Host,
>>> Cpus, Mem, Mem.
>>> The second Mem should be Disk instead.
>>>
>>> I suppose that should be easy to fix.
>>>
>>> Regards,
>>> Julian
>>>
>>
>>
>

Re: Marathon error

[Adam Bordelon]

Just because the Marathon scheduler is running, doesn't mean that it has
successfully registered with Mesos. Check the scheduler log and Mesos
master log for messages about attempted/failed registrations.

On Thu, May 19, 2016 at 4:28 AM,  wrote:

> Hi,
>
>
>
> Marathon service is running.
>
> But I don’t know why it’s not showing up in Mesos GUI ‘s frameworks.
>
>
>
>
>
> Thanks
>
>
>
> --
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Where allowed
> by local law, electronic communications with Accenture and its affiliates,
> including e-mail and instant messaging (including content), may be scanned
> by our systems for the purposes of information security and assessment of
> internal compliance with Accenture policy.
>
> __
>
> www.accenture.com
>

Re: 1.0 Release Candidate

[Adam Bordelon]

FYI, I made an alternate 1.0 release dashboard with a longer timeframe for
the created vs. resolved chart, and added a couple of my favorite widgets.
Feel free to use anything you find helpful.

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328256

On Thu, May 26, 2016 at 9:44 PM, Vinod Kone  wrote:

> This is the release dashboard:
>
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12328255
>
> *NOTE: *If you have set a Fix Version of 0.29.0 on a ticket that is not a
> blocker for 0.29.0/1.0 release, please unset the fix version.
>
> On Thu, May 26, 2016 at 3:44 PM, Vinod Kone  wrote:
>
>> Thanks for asking the questions Zameer. Wanted to give some clarification
>> regarding the thought process for releasing 1.0.
>>
>> The reason for cutting  a 1.0, is because we want to signal that the
>> Mesos project has reached a level of maturity to the wider community. Among
>> other things we are confident at this point that the *foundations* we laid
>> for the new APIs are mature and could be evolved in a backwards compatible
>> way. We laid the foundations almost an year ago (at last MesosCon) and
>> since then have been busy implementing the backend to drive the API.  Even
>> the newly released design doc for the operator API is built on the same
>> foundations as the scheduler/executor APIs. While we have been tweaking the
>> API backend for a while now the API definitions have mostly stayed the
>> same. Part of the reason it took this long is because we really wanted to
>> be sure the basic building blocks were solid.
>>
>> MesosCon is a great opportunity for us to drum up excitement about the
>> new APIs and invite them to start using/testing it. Like any other OSS
>> project, as people and organizations start using the new APIs in staging
>> and production, we will make stability and implementation improvements. The
>> long period for the RC will also help catching issues with API foundations
>> themselves. We have had a bit of chicken and egg problem having people
>> consume the new APIs because most don't want to use it in production unless
>> it is declared production ready and we can't call it production ready until
>> someone uses them in production.
>>
>> Having said all that stability and production readiness is paramount for
>> the project.  That is never going to change. In the case of the new APIs,
>> we have developed C++ frameworks using the new APIs and having been running
>> them as part of ASF CI for months now. Mesosphere, for example, also has an
>> internal cluster where frameworks using these new APIs have been baking for
>> a while and had done (and doing) rigorous tests (network partitions,
>> scaling tests, functional tests). Community members from IBM have also been
>> instrumental in testing the new APIs. We are hoping after 1.0 more people
>> would be willing and excited to consume these new APIs and stress test in
>> their environments.
>>
>> At the end of the day, while new APIs are an important part of Mesos 1.0
>> it's not the only reason for cutting a 1.0 release. Mesos has a slew of
>> exciting features and a thriving eco system and we would love to have more
>> people excited and get a taste of it. 1.0 is just a start...
>>
>> Hope that helps,
>>
>>
>> On Wed, May 25, 2016 at 4:57 PM, Zameer Manji  wrote:
>>
>>> I might be in the minority here, but I think cutting an RC for 1.0 right
>>> now is very aggressive. Does there exist even a single framework that
>>> uses
>>> the Scheduler HTTP API or the Executor HTTP API? Does anyone even use
>>> these
>>> APIs in production? Is there a single entity that uses the Operator API
>>> to
>>> manage agents?
>>>
>>> I think cutting an RC right now is 100% premature until the community can
>>> provide clear answers to these questions.
>>>
>>> I think Mesos project has been historically successful because its
>>> features
>>> were developed in a slow methodical manner and then battle tested by at
>>> least a user before the feature was declared 'stable' and ready for use
>>> for
>>> everyone. I think not following those steps here for the HTTP APIs is a
>>> huge error.
>>>
>>> On Wed, May 25, 2016 at 12:51 PM, Vinod Kone 
>>> wrote:
>>>
>>> > Post 1.0. Jie might be able to shed more light regarding the plans for
>>> > Docker Containerizer.
>>> >
>>> > On Wed, May 25, 2016 at 12:10 PM, Jeff Schroeder <
>>> > jeffschroe...@computer.org> wrote:
>>> >
>>> >> Does this mean the work to deprecate the docker containerizer will be
>>> >> post-1.0, or have those plans changed?
>>> >>
>>> >>
>>> >> On Wednesday, May 25, 2016, Vinod Kone  wrote:
>>> >>
>>> >>> Hi folks,
>>> >>>
>>> >>> As discussed in the previous community sync, we plan to cut a release
>>> >>> candidate for our next release (1.0) early next week.
>>> >>>
>>> >>> 1.0 is mainly centered around new APIs for Mesos. Please take a look
>>> at
>>> >>> MESOS-338  for
>>> >>> blocking issues. We got so

Re: Completed tasks logs missing from mesos UI

[Adam Bordelon]

Shakeel, if you're running a lot of short-lived frameworks/tasks on your
cluster, then your completed tasks may have fallen out of the master's
circular buffer. The master cannot (and should not) store all completed
tasks in memory, so we have configurable limits on how many a master will
keep in memory. See the following flags:
--max_completed_frameworks [default: 50]
"Maximum number of completed frameworks to store in memory."
--max_completed_tasks_per_framework [default: 1000]
"Maximum number of completed tasks per framework to store in memory."

On Wed, May 25, 2016 at 9:30 AM, Joseph Wu  wrote:

> Can you check that the ExecutorID and AgentID (actually SlaveID) match the
> path you found the logs on your box?
>
> See the diagram here for what each part of the path corresponds to each ID:
> http://mesos.apache.org/documentation/latest/sandbox/#where-is-it
>
> On Wed, May 25, 2016 at 3:04 AM, shakeel 
> wrote:
>
>> Hi,
>>
>> I am getting an error message similar to the one below when checking the
>> sandbox for a completed task.
>>
>> "Executor with ID  does not exist on slave with ID"
>>
>> However when I go on the slave, the logs are present.
>>
>> Has anyone come across this error before and how did you resolve it?
>>
>>
>> Kind Regards
>> Shakeel Suffee
>>
>> --
>> The information contained in this message is for the intended addressee
>> only and may contain confidential and/or privileged information. If you
>> are
>> not the intended addressee, please delete this message and notify the
>> sender; do not copy or distribute this message or disclose its contents to
>> anyone. Any views or opinions expressed in this message are those of the
>> author and do not necessarily represent those of Motortrak Limited or of
>> any of its associated companies. No reliance may be placed on this message
>> without written confirmation from an authorised representative of the
>> company.
>>
>> Registered in England 3098391 V.A.T. Registered No. 667463890
>>
>
>

Re: Framework Scheduling on Slave Question

[Adam Bordelon]

> Thus I’m trying to run a framework scheduler on a Mesos slave node.  I
that possible?
Absolutely. Marathon, Aurora, Singularity, and other "meta-frameworks" can
be used to launch other framework schedulers as Mesos tasks on agent nodes.
There's no reason you can't do the same thing for your own simulation
system.

> Does mesos-slave know how to pass scheduler requests back to a Mesos
master node?
Not really. Once the mesos-agent process has launched your sub-scheduler
process, it won't be involved in the rest of the scheduler API
communication between the sub-scheduler and mesos-master. To make that
work, the sub-scheduler must be started with information about how to
connect to the master, either via direct IPs, a ZK path, or a mesos-dns
name.

> Does one have to have mesos-master running on slave nodes to do this?
No. The process/container you run from the slave just has to be able to
reach the master, and the master must be able to reach the scheduler
process on its ip:port. You may want to override the auto-detected
LIBPROCESS_IP and LIBPROCESS_PORT, depending on your network configuration.

On Wed, May 25, 2016 at 7:40 AM, Shuai Lin  wrote:

>  Does mesos-slave know how to pass scheduler requests back to a Mesos
>> master node?  Does one have to have mesos-master running on slave nodes to
>> do this?  Am I smoking bad stuff?
>
>
> No problem at all. AFAIK it's a very common practice to have marathon
> running other frameworks.
>
> On Wed, May 25, 2016 at 9:52 AM, haosdent  wrote:
>
>> Hi, @Kent.
>>
>> > I’m trying to run a framework scheduler on a Mesos slave node.
>> > Does one have to have mesos-master running on slave nodes to do this?
>> If you mean run it manually, your could start your scheduler in any
>> machine, just make sure the network connection works between framework and
>> Mesos master.
>>
>> > Does mesos-slave know how to pass scheduler requests back to a Mesos
>> master node?
>> Framework only could communicate with Mesos Master, could not send
>> message to Mesos Slave directly unless forward via Mesos Master.
>>
>>
>> On Wed, May 25, 2016 at 3:14 AM, Kent Harris  wrote:
>>
>>> Pardon me if this is a newbie question.  I’m trying to port an existing
>>> simulation system that is comprised of many processes.  The master process
>>> is executed by a user (on a Mesos master node) and it has a custom
>>> Framework that simply launches a process, call it the “root” process”, via
>>> a CommandInfo executor on a slave node.
>>>
>>> The root process represents a simulation system and it needs to further
>>> schedule many processes that represent various parts of the simulation
>>> (communicating via ZMQ primarily).  To do this I have a second custom
>>> framework invoked by the root process that also uses  CommandInfo executor
>>> semantics to launch a number of tasks I call agents.  As an aside, all
>>> agents have a common base structure and a custom plugin structure where
>>> plugins represent different types of simulated hardware.
>>>
>>> Thus I’m trying to run a framework scheduler on a Mesos slave node.  I
>>> that possible?Does mesos-slave know how to pass scheduler requests back
>>> to a Mesos master node?  Does one have to have mesos-master running on
>>> slave nodes to do this?  Am I smoking bad stuff?
>>>
>>> Advice appreciated.
>>>
>>> - Kent
>>
>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>

Re: Executor downloads for every task

[Adam Bordelon]

Fetcher cache is great for not re-downloading the binary, but you might
also consider if you just want a long-lived executor that survives without
any tasks, awaiting new tasks to eventually come its way. That approach
uses up some resources while the executor idles, but could dramatically
decrease task launch time, if you're just spawning a thread instead of a
container/process.

On Wed, Jun 29, 2016 at 6:45 AM, Tomek Janiszewski 
wrote:

> You can use Fetching through the cache
>  to download file
> only once.
>
> śr., 29.06.2016 o 15:19 użytkownik Scott Weiss 
> napisał:
>
>> Every time my framework launches a task, it downloads the (custom)
>> executor from the URI I provide. then when the task finishes executing, the
>> framework gets the message Executor lost. this seems to cause the slaves to
>> download the executor binary every time they launch a task. Is there a way
>> to keep the executor binary on the slaves so it only has to be downloaded
>> one time?
>>
>

Re: [VOTE] Release Apache Mesos 1.0.0 (rc4)

[Adam Bordelon]

I don't like the idea of 2) bypassing the 72 hour voting period, so I'd
suggest either we:
1a) ask Yan to cancel his -1 so we can cut 1.0.0 today and blog about it,
then cut 1.0.1 soon after with this and other fixes.
1b) cut an rc5 now and the blogs posted tomorrow mention the rc rather than
an official release. After 72hrs we can hopefully call rc5 the official 1.0
(or maybe more blockers come up). We could have more blogs/press then about
the official 1.0 release.
1c) push the press releases and announcements out a few more days. Not sure
if this is possible at this point?
I'd prefer 1c) if possible, or a/b otherwise.

On Tue, Jul 26, 2016 at 6:52 PM, Benjamin Hindman <
benjamin.hind...@gmail.com> wrote:

> I agree with Vinod that we should go with option 1. I think redirect is a
> valuable feature but it's not imperative for the operation of the cluster.
>
> On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone  wrote:
>
>> We've the ASF press wire and other community blog posts lined up to be
>> posted tomorrow, so it will be really hard to tell all those folks to
>> postpone it this late. I've a couple options that I want to propose
>>
>> 1) Fix the webui bug in 1.0.1 which we will cut as soon as we fix this
>> bug.
>>
>> 2) Try to fix the bug in the next couple hours, cut rc5, and vote it in
>> tonight without doing the typical 72 hour voting period.
>>
>>
>> I'm personally leaning towards 1) given the timing and the nature of the
>> bug. What do others think? PMC?
>>
>> On Tue, Jul 26, 2016 at 4:08 PM, Yan Xu  wrote:
>>
>>> I don't mind if it's shepherd by folks with more front-end expertise.
>>> Actually my original suggested solution on
>>> https://issues.apache.org/jira/browse/MESOS-5911 seemed incorrect.
>>> Let's discuss the actual fix on the ticket, I feel that a short term fix
>>> shouldn't be more than a few lines to unblock the release.
>>>
>>> On Jul 26, 2016, at 3:26 PM, Jie Yu  wrote:
>>>
>>> Yan, are you going to shepherd the fix for this one? If yes, when do you
>>> think it can be done?
>>>
>>> - Jie
>>>
>>> On Tue, Jul 26, 2016 at 3:05 PM, Yan Xu  wrote:
>>>
>>> -1
>>>
>>> We tested it in our testing environment but webUI redirect didn't work.
>>> We
>>> filed: https://issues.apache.org/jira/browse/MESOS-5911
>>>
>>> Given that webUI is the portal for Mesos clusters I feel that we should
>>> at
>>> least have a basic fix (more context in the JIRA) before release 1.0.
>>> Thoughts?
>>>
>>> On Jul 26, 2016, at 2:52 PM, Kapil Arya  wrote:
>>>
>>> +1 (binding)
>>>
>>> OpenSUSE Tumbleweed:
>>>./configure --disable-java --disable-python && make check
>>>
>>> On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li 
>>> wrote:
>>>
>>> Also tested:
>>>
>>> make check passes on OS X
>>>
>>> One thing I found when testing RC4 debian with Aurora integration test
>>> suite (on its master) is that scheduler previously expected GPU resource
>>> will not receive offers without new `GPU_RESOURCES` capability even it's
>>> the only scheduler.
>>>
>>> Given that GPU support is not technically released until 1.0, I don't
>>> consider this is a blocker to me, but it might be surprising to people
>>> already testing GPU support.
>>>
>>> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler 
>>> wrote:
>>>
>>> +1 (binding)
>>>
>>> OS X 10.11.6
>>> ./configure --disable-python --disable-java
>>> make check
>>>
>>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann  wrote:
>>>
>>> +1 (non-binding)
>>>
>>> * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>>>
>>> test
>>>
>>> failure: ExamplesTest.PythonFramework fails for me the first time it's
>>> executed as part of the whole test suite, and then succeeds on
>>>
>>> subsequent
>>>
>>> executions. I'm investigating further, and will file a ticket if
>>>
>>> necessary.
>>>
>>> * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>>>
>>> Cheers,
>>> Greg
>>>
>>> On Tue, Jul 26, 2016 at 1:58 AM, haosdent  wrote:
>>>
>>> +1
>>>
>>> * make check in CentOS 7.2
>>> * make check in Ubuntu 14.04
>>> * test upgrade from 0.28.2 to 1.0.0-rc4
>>>
>>>
>>> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya 
>>>
>>> wrote:
>>>
>>>
>>> One can find the deb/rpm packages here:
>>>
>>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>>>
>>>
>>> And here are the corresponding docker images based off of Ubuntu
>>>
>>> 14.04:
>>>
>>>mesosphere/mesos:1.0.0-rc4
>>>mesosphere/mesos-master:1.0.0-rc4
>>>mesosphere/mesos-slave:1.0.0-rc4
>>>
>>> Kapil
>>>
>>> On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone 
>>>
>>> wrote:
>>>
>>>
>>> Hi all,
>>>
>>>
>>> Please vote on releasing the following candidate as Apache Mesos
>>>
>>> 1.0.0.
>>>
>>>
>>> *The vote is open until Tue Jul 25 11:00:00 PDT 2016 and passes
>>>
>>> if a
>>>
>>> majority of at least 3 +1 PMC votes are cast.*
>>>
>>> 1.0.0 includes the following:
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>
>>>  * Scheduler and Executor v

Re: [VOTE] Release Apache Mesos 1.0.1 (rc1)

[Adam Bordelon]

+1 (binding)
We've been running this in our internal soak cluster for a while now, and
it's nice and stable.

P.S. Can we call the result of this vote now?

On Mon, Aug 15, 2016 at 11:45 AM, Zhitao Li  wrote:

> +1 (nonbinding)
>
> Deployed a build to smaller testing cluster and no issue is found.
>
> On Mon, Aug 15, 2016 at 11:15 AM, Yan Xu  wrote:
>
> > +1 (binding)
> >
> > Ran make check on macOS 10.11.5 and clang-703.0.31.
> > Additionally, although not rigorous enough as a proof, we deployed a
> > version of head (> 1.0) that includes fixes in this release and it's
> > working fine (checked that webUI redirect worked and our test workloads
> > ran).
> >
> > Yan
> >
> > On Aug 13, 2016, at 6:38 AM, haosdent  wrote:
> >
> > +1 (non-binding)
> >
> > Run `sudo make check` on CentOS 7.2 and Ubuntu 14.04
> >
> > On Sat, Aug 13, 2016 at 6:07 AM, Kapil Arya  wrote:
> >
> >> +1 (binding)
> >>
> >> You can find the rpm/deb packages here:
> >>   http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.1-rc1
> >>
> >> The following docker tags (built off of ubuntu 14.04) are also
> available:
> >> mesosphere/mesos:1.0.1-rc1
> >> mesosphere/mesos-master:1.0.1-rc1
> >> mesosphere/mesos-slave:1.0.1-rc1
> >>
> >> Kapil
> >>
> >> On Fri, Aug 12, 2016 at 4:39 PM, Alex Rukletsov 
> >> wrote:
> >>
> >>> +1 (binding)
> >>>
> >>> make check on Mac OS 10.11.6 with apple clang-703.0.31.
> >>>
> >>> DockerFetcherPluginTest.INTERNET_CURL_FetchImage is flaky
> (MESOS-4570),
> >>> but
> >>> this does not seem to be a regression or a blocker.
> >>>
> >>> On Fri, Aug 12, 2016 at 10:30 PM, Radoslaw Gruchalski <
> >>> ra...@gruchalski.com>
> >>> wrote:
> >>>
> >>> > I am trying to build Mesos 1.0.1 for Centos 7 in a Docker container
> but
> >>> > I'm hitting this: https://issues.apache.org/jira/browse/MESOS-5925.
> >>> >
> >>> > Kind regards,
> >>> >
> >>> > Radek Gruchalski
> >>> > ra...@gruchalski.com
> >>> > +4917685656526
> >>> >
> >>> > *Confidentiality:*
> >>> > This communication is intended for the above-named person and may be
> >>> > confidential and/or legally privileged.
> >>> > If it has come to you in error you must take no action based on it,
> nor
> >>> > must you copy or show it to anyone; please delete/destroy and inform
> >>> the
> >>> > sender immediately.
> >>> >
> >>> > On Thu, Aug 11, 2016 at 2:32 AM, Vinod Kone 
> >>> wrote:
> >>> >
> >>> >> Hi all,
> >>> >>
> >>> >>
> >>> >> Please vote on releasing the following candidate as Apache Mesos
> >>> 1.0.1.
> >>> >>
> >>> >>
> >>> >> The CHANGELOG for the release is available at:
> >>> >>
> >>> >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
> >>> >> lain;f=CHANGELOG;hb=1.0.1-rc1
> >>> >>
> >>> >> 
> >>> >> 
> >>> >>
> >>> >>
> >>> >> The candidate for Mesos 1.0.1 release is available at:
> >>> >>
> >>> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/mesos
> >>> -1.0.1.tar.gz
> >>> >>
> >>> >>
> >>> >> The tag to be voted on is 1.0.1-rc1:
> >>> >>
> >>> >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit
> >>> ;h=1.0.1-rc1
> >>> >>
> >>> >>
> >>> >> The MD5 checksum of the tarball can be found at:
> >>> >>
> >>> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/mesos
> >>> >> -1.0.1.tar.gz.md5
> >>> >>
> >>> >>
> >>> >> The signature of the tarball can be found at:
> >>> >>
> >>> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/mesos
> >>> >> -1.0.1.tar.gz.asc
> >>> >>
> >>> >>
> >>> >> The PGP key used to sign the release is here:
> >>> >>
> >>> >> https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>> >>
> >>> >>
> >>> >> The JAR is up in Maven in a staging repository here:
> >>> >>
> >>> >> https://repository.apache.org/content/repositories/orgapache
> >>> mesos-1155
> >>> >>
> >>> >>
> >>> >> Please vote on releasing this package as Apache Mesos 1.0.1!
> >>> >>
> >>> >>
> >>> >> The vote is open until Mon Aug 15 17:29:33 PDT 2016 and passes if a
> >>> >> majority of at least 3 +1 PMC votes are cast.
> >>> >>
> >>> >>
> >>> >> [ ] +1 Release this package as Apache Mesos 1.0.1
> >>> >>
> >>> >> [ ] -1 Do not release this package because ...
> >>> >>
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >
> >>> >
> >>>
> >>
> >>
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
> >
> >
> >
>
>
> --
> Cheers,
>
> Zhitao Li
>

Mesos 1.2.0

[Adam Bordelon]

It's about time for Mesos 1.2.0, given our two-month release cadence. I
volunteer to be release manager, and I'd like to get a new committer or two
to help out. Any volunteers?

I expect to cut rc1 in early January, once all Blockers (and most Critical
issues) have been resolved/deferred. Here's how you can help:
- Set *Target Version = "1.2.0"* for anything that needs to go into this
release. Anything not critical can wait for Mesos 1.3.
- Upgrade release blockers to *"Blocker" priority*. Use "Critical" for any
issues that would be painful (but possible) to ship Mesos 1.2 without.

Mesos 1.2 release dashboard:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12329897

Cheers,
-Adam-

Re: Mesos 1.2.0

[Adam Bordelon]

Mesos 1.2.0 status update:
- We have 12 blockers
<https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20!%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
left, 7 of which are not yet "In Progress", 5 without a Shepherd, 2
Unassigned.
- I don't foresee us cutting an rc1 for at least another week while we work
on these remaining blockers.
- There are another ~50 issues targeted for 1.2, so squeeze them in this
week if you can.
- Your help is appreciated a) fixing blockers, b) updating JIRAs, and
c) *documenting
your new features.*

Release dashboard:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12329897

On Mon, Dec 26, 2016 at 7:04 PM, Adam Bordelon  wrote:

> It's about time for Mesos 1.2.0, given our two-month release cadence. I
> volunteer to be release manager, and I'd like to get a new committer or two
> to help out. Any volunteers?
>
> I expect to cut rc1 in early January, once all Blockers (and most Critical
> issues) have been resolved/deferred. Here's how you can help:
> - Set *Target Version = "1.2.0"* for anything that needs to go into this
> release. Anything not critical can wait for Mesos 1.3.
> - Upgrade release blockers to *"Blocker" priority*. Use "Critical" for
> any issues that would be painful (but possible) to ship Mesos 1.2 without.
>
> Mesos 1.2 release dashboard: https://issues.apache.org/
> jira/secure/Dashboard.jspa?selectPageId=12329897
>
> Cheers,
> -Adam-
>

Re: Mesos 1.2.0

[Adam Bordelon]

Mesos 1.2.0 status update:
- 5 blockers
<https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20%21%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
left: 2 for Anand/Vinod, 2 for BenH/Jie, and 1 for Gilbert/Jie.
- Once I cut the rc1, we'll vote, and likely find other blocker/critical
bug-fixes to cherry-pick on top for rc2. New features landing in master
will not be cherry-picked into 1.2.x.
- MESOS-5931 <https://issues.apache.org/jira/browse/MESOS-5931> (and
MESOS-6904 <https://issues.apache.org/jira/browse/MESOS-6904>) smell like
"features", so I'll hold off on cutting the rc1 until after they land,
hopefully by Monday. We're getting so close!

Release dashboard: https://issues.apache.org/jira/secure/Dashboard.jspa?
selectPageId=12329897

On Mon, Jan 9, 2017 at 7:02 AM, Adam Bordelon  wrote:

> Mesos 1.2.0 status update:
> - We have 12 blockers
> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20!%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
> left, 7 of which are not yet "In Progress", 5 without a Shepherd, 2
> Unassigned.
> - I don't foresee us cutting an rc1 for at least another week while we
> work on these remaining blockers.
> - There are another ~50 issues targeted for 1.2, so squeeze them in this
> week if you can.
> - Your help is appreciated a) fixing blockers, b) updating JIRAs, and c) 
> *documenting
> your new features.*
>
> Release dashboard: https://issues.apache.org/jira/secure/Dashboard.jspa?
> selectPageId=12329897
>
> On Mon, Dec 26, 2016 at 7:04 PM, Adam Bordelon  wrote:
>
>> It's about time for Mesos 1.2.0, given our two-month release cadence. I
>> volunteer to be release manager, and I'd like to get a new committer or two
>> to help out. Any volunteers?
>>
>> I expect to cut rc1 in early January, once all Blockers (and most
>> Critical issues) have been resolved/deferred. Here's how you can help:
>> - Set *Target Version = "1.2.0"* for anything that needs to go into this
>> release. Anything not critical can wait for Mesos 1.3.
>> - Upgrade release blockers to *"Blocker" priority*. Use "Critical" for
>> any issues that would be painful (but possible) to ship Mesos 1.2 without.
>>
>> Mesos 1.2 release dashboard: https://issues.apache.org/jira
>> /secure/Dashboard.jspa?selectPageId=12329897
>>
>> Cheers,
>> -Adam-
>>
>
>

Re: Mesos 1.2.0

[Adam Bordelon]

Mesos 1.2.0 now has *0 blockers left*! I'll cut the 1.2.0-rc1 from master
tomorrow.
There are still 6 Critical issues and 16 Major issues with
targetVersion/fixVersion set to 1.2.0 though.
Finish them before the cut tomorrow, or you'll have to beg me to
cherry-pick them instead of deferring them to 1.3.

Release dashboard: https://issues.apache.org/jira
/secure/Dashboard.jspa?selectPageId=12329897

On Fri, Jan 27, 2017 at 3:45 AM, Adam Bordelon  wrote:

> Mesos 1.2.0 status update:
> - 5 blockers
> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20%21%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
> left: 2 for Anand/Vinod, 2 for BenH/Jie, and 1 for Gilbert/Jie.
> - Once I cut the rc1, we'll vote, and likely find other blocker/critical
> bug-fixes to cherry-pick on top for rc2. New features landing in master
> will not be cherry-picked into 1.2.x.
> - MESOS-5931 <https://issues.apache.org/jira/browse/MESOS-5931> (and
> MESOS-6904 <https://issues.apache.org/jira/browse/MESOS-6904>) smell like
> "features", so I'll hold off on cutting the rc1 until after they land,
> hopefully by Monday. We're getting so close!
>
> Release dashboard: https://issues.apache.org/jira
> /secure/Dashboard.jspa?selectPageId=12329897
>
> On Mon, Jan 9, 2017 at 7:02 AM, Adam Bordelon  wrote:
>
>> Mesos 1.2.0 status update:
>> - We have 12 blockers
>> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20!%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
>> left, 7 of which are not yet "In Progress", 5 without a Shepherd, 2
>> Unassigned.
>> - I don't foresee us cutting an rc1 for at least another week while we
>> work on these remaining blockers.
>> - There are another ~50 issues targeted for 1.2, so squeeze them in this
>> week if you can.
>> - Your help is appreciated a) fixing blockers, b) updating JIRAs, and c) 
>> *documenting
>> your new features.*
>>
>> Release dashboard: https://issues.apache.org/jira
>> /secure/Dashboard.jspa?selectPageId=12329897
>>
>> On Mon, Dec 26, 2016 at 7:04 PM, Adam Bordelon 
>> wrote:
>>
>>> It's about time for Mesos 1.2.0, given our two-month release cadence. I
>>> volunteer to be release manager, and I'd like to get a new committer or two
>>> to help out. Any volunteers?
>>>
>>> I expect to cut rc1 in early January, once all Blockers (and most
>>> Critical issues) have been resolved/deferred. Here's how you can help:
>>> - Set *Target Version = "1.2.0"* for anything that needs to go into
>>> this release. Anything not critical can wait for Mesos 1.3.
>>> - Upgrade release blockers to *"Blocker" priority*. Use "Critical" for
>>> any issues that would be painful (but possible) to ship Mesos 1.2 without.
>>>
>>> Mesos 1.2 release dashboard: https://issues.apache.org/jira
>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>
>>> Cheers,
>>> -Adam-
>>>
>>
>>
>

Re: [VOTE] Release Apache Mesos 1.0.3 (rc2)

[Adam Bordelon]

+1 binding

Tests passed against DC/OS 1.8.8 (prerelease), which is based on the Apache
Mesos 1.0.x branch.
https://github.com/dcos/dcos/pull/1210

On Wed, Feb 1, 2017 at 10:01 AM, Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI
>
>
> *Revision*: c673fdd00e7f93ab7844965435d57fd691fb4d8d
>
>- refs/tags/1.0.3-rc2
>
> 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: Success]
> 
> [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: Success]
> 
> [image: Success]
> 
>
> On Tue, Jan 31, 2017 at 11:46 AM, Vinod Kone  wrote:
>
>> Hi all,
>>
>>
>> Please vote on releasing the following candidate as Apache Mesos 1.0.3.
>>
>>
>> 1.0.3 includes the following:
>>
>> 
>> 
>>
>> * [MESOS-6052] - Unable to launch containers on CNI networks on
>> CoreOS
>>
>> * [MESOS-6142] - Frameworks may RESERVE for an arbitrary role.
>>
>>
>> * [MESOS-6621] - SSL downgrade path will CHECK-fail when using both
>> temporary and persistent sockets
>>
>> * [MESOS-6676] - Always re-link with scheduler during
>> re-registration.
>>
>> * [MESOS-6917] - Segfault when the executor sets an invalid UUID when
>> sending a status update.
>>
>>
>> The CHANGELOG for the release is available at:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>> lain;f=CHANGELOG;hb=1.0.3-rc2
>>
>> 
>> 

Re: Mesos 1.2.0

[Adam Bordelon]

Good news, everyone!

Mesos 1.2.0-rc1 has been cut, the `1.2.x` branch has been created, and the
version in `master` was bumped to 1.3.0!
This was delayed due to last-minute blockers and personal issues with the
mvn gpg plugin. :(
As of now, please set fixVersion to 1.3.0 for any newly resolved tickets
landing in master.

I won't call for a vote on rc1 because we still need to update the
CHANGELOG and docs and cut an rc2.
So, if you have any really critical issues landing in the next couple of
days, you can beg me to cherry-pick them.
And if you haven't written user docs for the major features in 1.2.0,
please commit those ASAP and notify me.

Current 1.2.0 feature list:
- Container Attach/Exec [NEEDS DOCS]
- Linux capabilities and rLimit support for Mesos containerizer [has docs]
- Support auto backend in Unified Containerizer. [has docs]
- Support docker registry that requires basic auth.[NEEDS DOCS]
- Distributed HTTP(S) and TCP Health Checks [has docs]
- Authz for Agent v1 Operator API [NEEDS DOCS?]
- Teardown unregistered frameworks [NEEDS DOCS?]

Please let me know if I've missed something.

On Thu, Feb 2, 2017 at 2:24 PM, Adam Bordelon  wrote:

> Mesos 1.2.0 now has *0 blockers left*! I'll cut the 1.2.0-rc1 from master
> tomorrow.
> There are still 6 Critical issues and 16 Major issues with
> targetVersion/fixVersion set to 1.2.0 though.
> Finish them before the cut tomorrow, or you'll have to beg me to
> cherry-pick them instead of deferring them to 1.3.
>
> Release dashboard: https://issues.apache.org/jira
> /secure/Dashboard.jspa?selectPageId=12329897
>
> On Fri, Jan 27, 2017 at 3:45 AM, Adam Bordelon  wrote:
>
>> Mesos 1.2.0 status update:
>> - 5 blockers
>> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20%21%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
>> left: 2 for Anand/Vinod, 2 for BenH/Jie, and 1 for Gilbert/Jie.
>> - Once I cut the rc1, we'll vote, and likely find other blocker/critical
>> bug-fixes to cherry-pick on top for rc2. New features landing in master
>> will not be cherry-picked into 1.2.x.
>> - MESOS-5931 <https://issues.apache.org/jira/browse/MESOS-5931> (and
>> MESOS-6904 <https://issues.apache.org/jira/browse/MESOS-6904>) smell
>> like "features", so I'll hold off on cutting the rc1 until after they land,
>> hopefully by Monday. We're getting so close!
>>
>> Release dashboard: https://issues.apache.org/jira
>> /secure/Dashboard.jspa?selectPageId=12329897
>>
>> On Mon, Jan 9, 2017 at 7:02 AM, Adam Bordelon  wrote:
>>
>>> Mesos 1.2.0 status update:
>>> - We have 12 blockers
>>> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20!%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
>>> left, 7 of which are not yet "In Progress", 5 without a Shepherd, 2
>>> Unassigned.
>>> - I don't foresee us cutting an rc1 for at least another week while we
>>> work on these remaining blockers.
>>> - There are another ~50 issues targeted for 1.2, so squeeze them in this
>>> week if you can.
>>> - Your help is appreciated a) fixing blockers, b) updating JIRAs, and c) 
>>> *documenting
>>> your new features.*
>>>
>>> Release dashboard: https://issues.apache.org/jira
>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>
>>> On Mon, Dec 26, 2016 at 7:04 PM, Adam Bordelon 
>>> wrote:
>>>
>>>> It's about time for Mesos 1.2.0, given our two-month release cadence. I
>>>> volunteer to be release manager, and I'd like to get a new committer or two
>>>> to help out. Any volunteers?
>>>>
>>>> I expect to cut rc1 in early January, once all Blockers (and most
>>>> Critical issues) have been resolved/deferred. Here's how you can help:
>>>> - Set *Target Version = "1.2.0"* for anything that needs to go into
>>>> this release. Anything not critical can wait for Mesos 1.3.
>>>> - Upgrade release blockers to *"Blocker" priority*. Use "Critical" for
>>>> any issues that would be painful (but possible) to ship Mesos 1.2 without.
>>>>
>>>> Mesos 1.2 release dashboard: https://issues.apache.org/jira
>>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>>
>>>> Cheers,
>>>> -Adam-
>>>>
>>>
>>>
>>
>

Re: Mesos 1.2.0

[Adam Bordelon]

No, that's not part of the 1.2.0 release, but it is under consideration for
the executor authentication work that Greg is leading for 1.3.

On Sat, Feb 11, 2017 at 7:55 AM, l zc  wrote:

> Hi, Did we support domain socket between agent and executor in mesos 1.2,0
> ?
>
> 发件人: Adam Bordelon 
> 答复: "user@mesos.apache.org" 
> 日期: 2017年2月10日 星期五 上午9:56
> 至: dev , "user@mesos.apache.org" <
> user@mesos.apache.org>
> 主题: Re: Mesos 1.2.0
>
> Good news, everyone!
>
> Mesos 1.2.0-rc1 has been cut, the `1.2.x` branch has been created, and the
> version in `master` was bumped to 1.3.0!
> This was delayed due to last-minute blockers and personal issues with the
> mvn gpg plugin. :(
> As of now, please set fixVersion to 1.3.0 for any newly resolved tickets
> landing in master.
>
> I won't call for a vote on rc1 because we still need to update the
> CHANGELOG and docs and cut an rc2.
> So, if you have any really critical issues landing in the next couple of
> days, you can beg me to cherry-pick them.
> And if you haven't written user docs for the major features in 1.2.0,
> please commit those ASAP and notify me.
>
> Current 1.2.0 feature list:
> - Container Attach/Exec [NEEDS DOCS]
> - Linux capabilities and rLimit support for Mesos containerizer [has docs]
> - Support auto backend in Unified Containerizer. [has docs]
> - Support docker registry that requires basic auth.[NEEDS DOCS]
> - Distributed HTTP(S) and TCP Health Checks [has docs]
> - Authz for Agent v1 Operator API [NEEDS DOCS?]
> - Teardown unregistered frameworks [NEEDS DOCS?]
>
> Please let me know if I've missed something.
>
> On Thu, Feb 2, 2017 at 2:24 PM, Adam Bordelon  wrote:
>
>> Mesos 1.2.0 now has *0 blockers left*! I'll cut the 1.2.0-rc1 from
>> master tomorrow.
>> There are still 6 Critical issues and 16 Major issues with
>> targetVersion/fixVersion set to 1.2.0 though.
>> Finish them before the cut tomorrow, or you'll have to beg me to
>> cherry-pick them instead of deferring them to 1.3.
>>
>> Release dashboard: https://issues.apache.org/jira
>> /secure/Dashboard.jspa?selectPageId=12329897
>>
>> On Fri, Jan 27, 2017 at 3:45 AM, Adam Bordelon 
>> wrote:
>>
>>> Mesos 1.2.0 status update:
>>> - 5 blockers
>>> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20%21%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
>>> left: 2 for Anand/Vinod, 2 for BenH/Jie, and 1 for Gilbert/Jie.
>>> - Once I cut the rc1, we'll vote, and likely find other blocker/critical
>>> bug-fixes to cherry-pick on top for rc2. New features landing in master
>>> will not be cherry-picked into 1.2.x.
>>> - MESOS-5931 <https://issues.apache.org/jira/browse/MESOS-5931> (and
>>> MESOS-6904 <https://issues.apache.org/jira/browse/MESOS-6904>) smell
>>> like "features", so I'll hold off on cutting the rc1 until after they land,
>>> hopefully by Monday. We're getting so close!
>>>
>>> Release dashboard: https://issues.apache.org/jira
>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>
>>> On Mon, Jan 9, 2017 at 7:02 AM, Adam Bordelon 
>>> wrote:
>>>
>>>> Mesos 1.2.0 status update:
>>>> - We have 12 blockers
>>>> <https://issues.apache.org/jira/issues/?jql=filter%20%3D%20%22Mesos%201.2%22%20AND%20status%20!%3D%20Resolved%20AND%20priority%20%3D%20Blocker%20ORDER%20BY%20status%20ASC%2C%20assignee%20DESC>
>>>> left, 7 of which are not yet "In Progress", 5 without a Shepherd, 2
>>>> Unassigned.
>>>> - I don't foresee us cutting an rc1 for at least another week while we
>>>> work on these remaining blockers.
>>>> - There are another ~50 issues targeted for 1.2, so squeeze them in
>>>> this week if you can.
>>>> - Your help is appreciated a) fixing blockers, b) updating JIRAs, and
>>>> c) * documenting your new features.*
>>>>
>>>> Release dashboard: https://issues.apache.org/jira
>>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>>
>>>> On Mon, Dec 26, 2016 at 7:04 PM, Adam Bordelon 
>>>> wrote:
>>>>
>>>>> It's about time for Mesos 1.2.0, given our two-month release cadence.
>>>>> I volunteer to be release manager, and I'd like to get a new committer or
>>>>> two to help out. Any volunteers?
>>>>>
>>>>> I expect to cut rc1 in early January, once all Blockers (and most
>>>>> Critical issues) have been resolved/deferred. Here's how you can help:
>>>>> - Set *Target Version = "1.2.0"* for anything that needs to go into
>>>>> this release. Anything not critical can wait for Mesos 1.3.
>>>>> - Upgrade release blockers to *"Blocker" priority*. Use "Critical"
>>>>> for any issues that would be painful (but possible) to ship Mesos 1.2
>>>>> without.
>>>>>
>>>>> Mesos 1.2 release dashboard: https://issues.apache.org/jira
>>>>> /secure/Dashboard.jspa?selectPageId=12329897
>>>>>
>>>>> Cheers,
>>>>> -Adam-
>>>>>
>>>>
>>>>
>>>
>>
>

[VOTE] Release Apache Mesos 1.2.0 (rc2)

[Adam Bordelon]

Dear Mesos developers and users,

Please vote on releasing the following candidate as Apache Mesos 1.2.0.

1.2.0 includes the following:

  * [MESOS-5931] - **Experimental** Support auto backend in Mesos
Containerizer,
prefering overlayfs then aufs. Please note that the bind backend needs
to be
specified explicitly through the agent flag
'--image_provisioner_backend'
since it requires the sandbox already existed.

  * [MESOS-6402] - **Experimental** Add rlimit support to Mesos
containerizer.
The isolator adds support for setting POSIX resource limits (rlimits)
for
containers launched using the Mesos containerizer. POSIX rlimits can be
used
to control the resources a process can consume. See `docs/
posix_rlimits.md`
for details.

  * [MESOS-6419] - **Experimental** Teardown unregistered frameworks. The
master
now treats recovered frameworks very similarly to frameworks that are
registered
but currently disconnected. For example, recovered frameworks will be
reported
via the normal "frameworks" key when querying HTTP endpoints. This
means there
is no longer a concept of "orphan tasks": if the master knows about a
task, the
task will be running under a framework. Similarly, "teardown"
operations on
recovered frameworks will now work correctly.

  * [MESOS-6460] - **Experimental** Container Attach and Exec. This feature
adds
new Agent APIs for attaching a remote client to the stdin, stdout, and
stderr
of a running Mesos task, as well as an API for launching new processes
inside
the same container as a running Mesos task and attaching to its stdin,
stdout,
and stderr. At a high level, these APIs mimic functionality similar to
docker
attach and docker exec. The primary motivation for such functionality
is to
enable users to debug their running Mesos tasks.

  * [MESOS-6758] - **Experimental** Support 'Basic' auth docker private
registry
on Mesos Containerizer. Until now, the mesos containerizer always
assumed
Bearer auth, but we now also support basic auth for private registries.
Please
note that the AWS ECS uses Basic authorization but it does not work yet
due to
the redirect issue MESOS-5172.

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.2.0-rc2


The candidate for Mesos 1.2.0 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.0-rc2/mesos-1.2.0.tar.gz

The tag to be voted on is 1.2.0-rc2:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.2.0-rc2

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.0-rc2/mesos-1.2.0.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.0-rc2/mesos-1.2.0.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1180

Please vote on releasing this package as Apache Mesos 1.2.0!

The vote is open until Wed Mar 1 18:00 PST 2017 and passes if a majority of
at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 1.2.0
[ ] -1 Do not release this package because ...

Thanks,
-Adam-

Re: [VOTE] Release Apache Mesos 1.2.0 (rc2)

[Adam Bordelon]

os-
> Release/30/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=-
> -verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > --verbose autotools
> > [image: Success]
> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,
> label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Failed]
> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/30/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,
> label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > cmake
> > [image: Success]
> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%
> 3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Success]
> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/30/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=-
> -verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%
> 3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> >
> > On Wed, Mar 1, 2017 at 9:24 AM, Greg Mann  wrote:
> >
> >> I wanted to give a heads up on a flaky test failure I've encountered
> while
> >> testing this RC: 'DockerRuntimeIsolatorTest.ROO
> >> T_INTERNET_CURL_DockerDefaultEntryptRegistryPuller'. One issue related
> to
> >> this test was resolved recently (https://issues.apache.org/
> >> jira/browse/MESOS-6001), but this seems to be a separate issue (
> >> https://issues.apache.org/jira/browse/MESOS-7185). I haven't had time
> to
> >> triage yet so I'm not sure if this represents a legitimate bug, but I
> >> thought I'd email here to increase visibility while the vote is out.
> >>
> >> Cheers,
> >> Greg
> >>
> >>
> >> On Fri, Feb 24, 2017 at 1:14 AM, Adam Bordelon 
> wrote:
> >>
> >> > Dear Mesos developers and users,
> >> >
> >> > Please vote on releasing the following candidate as Apache Mesos
> 1.2.0.
> >> >
> >> > 1.2.0 includes the following:
> >> > 
> >> > 
> >> >   * [MESOS-5931] - **Experimental** Support auto backend in Mesos
> >> > Containerizer,
> >> > prefering overlayfs then aufs. Please note that the bind backend
> >> needs
> >> > to be
> >> > specified explicitly through the agent flag
> >> > '--image_provisioner_backend'
> >> > since it requires the sandbox already existed.
> >> >
> >> >   * [MESOS-6402] - **Experimental** Add rlimit support to Mesos
> >> > containerizer.
> >> > The isolator adds support for setting POSIX resource limits
> (rlimits)
> >> > for
> >> > containers launched using the Mesos containerizer. POSIX rlimits
> can
> >> be
> >> > used
> >> > to control the resources a process can consume. See `docs/
> >> > posix_rlimits.md`
> >> > for details.
> >> >
> >> >   * [MESOS-6419] - **Experimental** Teardown unregistered frameworks.
> The
> >> > master
> >> > now treats recovered frameworks very similarly to frameworks that
> are
> >> > registered
> >> > but currently disconnected. For example, recovered frameworks
> will be
> >> > reported
> >> > via the normal "frameworks" key when querying HTTP endpoints. This
> >> > means there
> >> > is no longer a concept of "orphan tasks": if the master knows
> about a
> >> > task, the
> >> > task will be running under a framework. Similarly, "teardown"
> >> > operations on
> >> > recovered frameworks will now work correctly.
> >> >
> >> >   * [MESOS-6460] - **Experimental** Container Attach and Exec. This
> >> feature
> >> > adds
> >> > new Agent APIs for attaching a remote client to the stdin, stdout,
> 

Re: [VOTE] Release Apache Mesos 1.2.0 (rc2)

[Adam Bordelon]

I haven't heard any -1's so I'm going to go ahead and vote myself, from a
DC/OS perspective:

+1 (binding)

I ran 1.2.0-rc2 through the DC/OS integration tests on top of the
1.9.0-rc1, which covers many Mesos features and tests multiple frameworks.
See CI results of https://github.com/dcos/dcos/pull/1295

This was then merged into DC/OS 1.9.0-rc2 which passed another suite of
integration tests. Available for testing at
https://dcos.io/releases/1.9.0-rc2/


On Thu, Mar 2, 2017 at 12:02 AM, Adam Bordelon  wrote:

> TL;DR: No consensus yet. Let's extend the vote for a day or two, until we
> have 3 +1s or a legit -1.
> During that time we can test further, and investigate any issues that have
> shown up.
>
> Here's a summary of what's been reported on the 1.2.0-rc2 vote thread:
>
> - There was a perf core dump on ASF CI, which is not necessarily a blocker:
> MESOS-7160  Parsing of perf version segfaults
>   Perhaps fixed by backporting MESOS-6982: PerfTest.Version fails on
> recent Arch Linux
>
> - There were a couple of (known/unsurprising) flaky tests:
> MESOS-7185  DockerRuntimeIsolatorTest.ROOT_INTERNET_CURL_
> DockerDefaultEntryptRegistryPuller is flaky
> MESOS-4570  DockerFetcherPluginTest.INTERNET_CURL_FetchImage seems flaky.
>
> - If we were to have an rc3, the following Critical bugs could be included:
> MESOS-7050  IOSwitchboard FDs leaked when containerizer launch fails --
> leads to deadlock
> MESOS-6982  PerfTest.Version fails on recent Arch Linux
>
> - Plus doc updates:
> MESOS-7188 Add documentation for Debug APIs to Operator API doc
> MESOS-7189 Add nested container launch/wait/kill APIs to agent API
> docs.
>
>
> On Wed, Mar 1, 2017 at 11:30 AM, Neil Conway 
> wrote:
>
>> The perf core dump might be addressed if we backport this change:
>>
>> https://reviews.apache.org/r/56611/
>>
>> Although my guess is that this isn't a severe problem: for some
>> as-yet-unknown reason, running `perf` on the host segfaulted, which
>> causes the test to fail.
>>
>> Neil
>>
>> On Wed, Mar 1, 2017 at 11:09 AM, Vinod Kone  wrote:
>> > Tested on ASF CI.
>> >
>> > Saw 2 configurations fail. One was the perf core dump issue
>> > <https://issues.apache.org/jira/browse/MESOS-7160>. Other is a known
>> (since
>> > 0..28.0) flaky test with Docker fetcher plugin
>> > <https://issues.apache.org/jira/browse/MESOS-4570>.
>> >
>> > Withholding the vote until we know the severity of the perf core dump.
>> >
>> >
>> > *Revision*: b9d8202a7444d0d1e49476bfc9817eb4583beaff
>> >
>> >- refs/tags/1.1.1-rc2
>> >
>> > Configuration Matrix gcc clang
>> > centos:7 --verbose --enable-libevent --enable-ssl autotools
>> > [image: Success]
>> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>> ease/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--
>> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
>> GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%
>> 7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>> > [image: Not run]
>> > cmake
>> > [image: Success]
>> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>> ease/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose
>> %20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=
>> 1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%
>> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>> > [image: Not run]
>> > --verbose autotools
>> > [image: Success]
>> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>> ease/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--
>> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%
>> 3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>> > [image: Not run]
>> > cmake
>> > [image: Success]
>> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>> ease/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose
>> ,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
>> exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>> > [image: Not run]
>> > ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
>> > [image: Success]
>> > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>> ease/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--
>> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
>> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu

[RESULT][VOTE] Release Apache Mesos 1.2.0 (rc2)

[Adam Bordelon]

Hello devs and users,

The vote for Mesos 1.2.0 (rc2) has passed with the following votes:

+1 (Binding)
--
*** Adam B
*** Vinod Kone
*** Joseph Wu

-0
--
*** Jie Yu, for MESOS-7208

There were no -1 votes.

Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/1.2.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.2.0

The mesos-1.2.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,
-Adam-

Re: Debugging mesos-fetcher binary

[Adam Bordelon]

See the FetcherInfo protobuf definition:
https://github.com/apache/mesos/blob/master/include/mesos/fetcher/fetcher.proto#L33

On Mon, Mar 27, 2017 at 11:46 PM, Adam Cecile  wrote:

> Hello,
>
> Since a few version I'm not able to upgrade Mesos because it do not want
> to download packages from my Nexus server anymore.
>
> It complains about the SSL certificate, which is perfectly valid...
>
>
> Anyway... I'd like to run mesos-fetcher by hand to trigger the issue
> easily and checks system calls because I have some serious doubts regarding
> the CAs being used.
>
> It seems the tool expect a JSON file describing the file to be dowloaded
> as MESOS_FETCHER_INFO environment variable. Can you help me figuring out
> which format it is ?
>
>
> Thanks in advance,
>
>
> Regards, Adam.
>
>

Re: SSL certificate error (1.1.0 OK, 1.1.1 NOK: Error downloading resource: Problem with the SSL CA cert (path? access rights?))

[Adam Bordelon]

I found https://issues.apache.org/jira/browse/MESOS-7133 but that was
supposedly fixed in 1.1.1 (broken in 1.1.0)

On Tue, Mar 28, 2017 at 12:23 AM, Adam Cecile  wrote:

> Hello,
>
>
> Here is a simple test showing why I cannot upgrade Mesos anymore (Debian
> Jessie, using mesosphere packages):
>
>
> apt-get install mesos=1.1.0-2.0.107.debian81
>
> MESOS_FETCHER_INFO='{ "sandbox_directory": "/tmp/abc", "items": [ { "uri":
> { "value": "https://path/to/file }, "action": "BYPASS_CACHE" } ] }'
> /usr/libexec/mesos/mesos-fetcher
>
> [...] 0328 09:20:39.361690 129351 fetcher.cpp:547] Fetched '
> https://path/to/file' to '/tmp/abc/file'
>
>
> apt-get install mesos=1.1.1-2.0.1
>
> MESOS_FETCHER_INFO='{ "sandbox_directory": "/tmp/abc", "items": [ { "uri":
> { "value": "https://path/to/file }, "action": "BYPASS_CACHE" } ] }'
> /usr/libexec/mesos/mesos-fetcher
>
> [...] Failed to fetch 'https://path/to/file': Error downloading resource:
> Problem with the SSL CA cert (path? access rights?)
>
>
>
> Obviously the URL is working just fine when being retreive with CURL, WGET
> or a JAVA app from the server itself.
>
> Any hint would be appreciated !
>
>
> Best regards, Adam.
>

Re: [VOTE] Release Apache Mesos 1.0.4 (rc1)

[Adam Bordelon]

-0, wish we could include the fix for
https://issues.apache.org/jira/browse/MESOS-7265 in 1.0.4, but I won't hold
the release for it.

On Mon, Apr 17, 2017 at 3:44 PM, Vinod Kone  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.4.
>
>
> 1.0.4 includes the following:
>
> 
> 
>
> * [MESOS-2537] - AC_ARG_ENABLED checks are broken
>
>
> * [MESOS-6606] - Reject optimized builds with libcxx before 3.9
>
>
> * [MESOS-7008] - Quota not recovered from registry in empty cluster.
>
>
> * [MESOS-7366] - Agent sandbox gc could accidentally delete the entire
> persistent volume content.
>
> * [MESOS-7383] - Docker executor logs possibly sensitive parameters.
>
>
>
> 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.0.4-rc1
>
> 
> 
>
>
> The candidate for Mesos 1.0.4 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.4-rc1/mesos-1.0.4.tar.gz
>
>
> The tag to be voted on is 1.0.4-rc1:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.4-rc1
>
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.4-rc1/
> mesos-1.0.4.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.0.4-rc1/
> mesos-1.0.4.tar.gz.asc
>
>
> The PGP key used to sign the release is here:
>
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
>
> The JAR is up in Maven in a staging repository here:
>
> https://repository.apache.org/content/repositories/orgapachemesos-1184
>
>
> Please vote on releasing this package as Apache Mesos 1.0.4!
>
>
> The vote is open until Thu Apr 20 15:42:56 PDT 2017 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Mesos 1.0.4
>
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
>

[VOTE] Release Apache Mesos 1.2.1 (rc1)

[Adam Bordelon]

Hi all,

Please vote on releasing the following candidate as Apache Mesos 1.2.1.

1.2.1 is a bug fix release. 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.2.1-rc1

The candidate for Mesos 1.2.1 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/mesos-1.2.1.tar.gz

The tag to be voted on is 1.2.1-rc1:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.2.1-rc1

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/mesos-1.2.1.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/mesos-1.2.1.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1192

Please vote on releasing this package as Apache Mesos 1.2.1!

The vote is open until Tue May 16 17:00 PDT 2017 and passes if a majority
of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 1.2.1
[ ] -1 Do not release this package because ...

Thanks,
-Adam-

Re: [VOTE] Release Apache Mesos 1.2.1 (rc1)

[Adam Bordelon]

+1 (binding) Good enough for me.

Ran `make check` (or equivalent) on the Mesosphere internal Jenkins CI.
Lots of green (all tests passed) on Mac, CentOS7, Debian8, Fedora23 and
Ubuntu 12.04.
Three sets of yellow configs yielded 10 unique but mostly known
failing/flaky tests.
(Grey means untested)
[image: Inline image 1]

* Ubuntu {14.04|16.04|16.10} - {Plain|SSL|CMake|Clang}
  PerfTest.Version (always) -
https://issues.apache.org/jira/browse/MESOS-7160
  ExamplesTest.PythonFramework (sometimes) -
https://issues.apache.org/jira/browse/MESOS-7218

* Centos 6 - {Plain|SSL}
  DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes -
https://issues.apache.org/jira/browse/MESOS-7510

* Fedora 23 - Network_Isolator
  PortMappingIsolatorTest.ROOT_NC_HostToContainerUDP -
https://issues.apache.org/jira/browse/MESOS-5690
  PortMappingIsolatorTest.ROOT_ContainerICMPExternal -
https://issues.apache.org/jira/browse/MESOS-5689
  PortMappingIsolatorTest.ROOT_DNS -
https://issues.apache.org/jira/browse/MESOS-5688
  PortMappingIsolatorTest.ROOT_NC_SmallEgressLimit -
https://issues.apache.org/jira/browse/MESOS-5687
  PortMappingIsolatorTest.ROOT_NC_PortMappingStatistics - ?
  PortMappingMesosTest.CGROUPS_ROOT_RecoverMixedContainers - ?
  PortMappingMesosTest.CGROUPS_ROOT_RecoverMixedKnownAndUnKnownOrphans - ?

Anybody have any ideas on the last three? Seems like these PortMapping
tests are generally in a bad shape, or the network isolator is seriously
broken. I'll file JIRAs.

P.S. AgentAPIStreamingTest.AttachInputToNestedContainerSession Vinod saw on
ASF CI is flaky according to https://issues.apache.org/
jira/browse/MESOS-7159 (added the log gist link there)

P.P.S.  CI results at
https://jenkins.mesosphere.com/service/jenkins/job/mesos/job/Mesos_CI-build/1215
for those with access. We're still working on exposing our CI to the
public. Waiting is.


On Thu, Jun 8, 2017 at 4:23 PM, Benjamin Mahler  wrote:

> +1 (binding)
>
> make check passed on macOS 10.12.4
>
> The ContentType/AgentAPIStreamingTest.AttachInputToNestedContainerSession
> passed for me. Kevin, I captured the logs to the failed run vinod pointed
> to here:
>
> https://gist.github.com/bmahler/5ae340b4de3341f3c1f072250006dc64
>
> Does that look like a flaky test or a bug?
>
> On Thu, Jun 8, 2017 at 4:07 PM, Benjamin Mahler 
> wrote:
>
>> Vinod I think that's the getenv issue from: https://issues.apache.or
>> g/jira/browse/MESOS-6985
>>
>> On Wed, May 17, 2017 at 5:57 PM, Till Toenshoff  wrote:
>>
>>> +1
>>>
>>> Ran it through DC/OS builds and integration tests;
>>> https://github.com/dcos/dcos/pull/1530 => all green
>>>
>>> On May 17, 2017, at 10:01 PM, Vinod Kone  wrote:
>>>
>>> Ran it on ASF CI and saw some issues.
>>>
>>> Segfault in "MasterTest.MultipleExecutors" in two builds [1]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/35/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos:7,label_exp=%28docker%7C%7CHadoop%29&&%28%21ubuntu-us1%29&&%28%21ubuntu-eu2%29/consoleFull>
>>> [2
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/35/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos:7,label_exp=%28docker%7C%7CHadoop%29&&%28%21ubuntu-us1%29&&%28%21ubuntu-eu2%29/console>],
>>> which is concerning. Is this a known issue?
>>>
>>> "ContentType/AgentAPIStreamingTest.AttachInputToNestedContainerSession" 
>>> test failed 
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/35/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu:14.04,label_exp=%28docker%7C%7CHadoop%29&&%28%21ubuntu-us1%29&&%28%21ubuntu-eu2%29/consoleFull>.
>>>
>>>
>>>
>>>
>>> On Sun, May 14, 2017 at 12:55 AM, tommy xiao  wrote:
>>>
>>>> +1
>>>>
>>>> 2017-05-12 7:33 GMT+08:00 Adam Bordelon :
>>>>
>>>> > Hi all,
>>>> >
>>>> > Please vote on releasing the following candidate as Apache Mesos
>>>> 1.2.1.
>>>> >
>>>> > 1.2.1 is a bug fix release. 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.2.1-rc1
>>>> >
>>>> > The candidate for Mesos 1.2.1 release is available at:
>>>> > https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/mesos
>>&g

Re: [RESULT][VOTE] Release Apache Mesos 1.3.0 (rc3)

[Adam Bordelon]

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

On Wed, Jun 7, 2017 at 3:03 AM, Michael Park  wrote:

> Hi all,
>
> The vote for Mesos 1.3.0 (rc3) has passed with the
> following votes.
>
> +1 (Binding)
> --
> Vinod Kone
> Benjamin Mahler
> Yan Xu
>
> +1 (Non-binding)
> --
> N/A
>
> There were no 0 or -1 votes.
>
> Please find the release at:
> /1.3.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_p
> lain;f=CHANGELOG;hb=1.3.0
>
> The mesos-1.3.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,
>
> MPark & Neil
>

[RESULT][VOTE] Release Apache Mesos 1.2.1 (rc1)

[Adam Bordelon]

Hi all,

The vote for Mesos 1.2.1 (rc1) has passed with the following votes.

+1 (Binding)
--
Till Toenshoff
Benjamin Mahler
Adam Bordelon

+1 (Non-binding)
--
tommy xiao

There were no 0 or -1 votes.

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

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.2.1

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

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

Thanks,
-Adam-


On Mon, Jun 12, 2017 at 3:15 AM, Alex Rukletsov  wrote:

> PortMapping tests are indeed in bade shape. There are JIRAs already, have a
> look before filing new ones:
> MESOS-4646, MESOS-5687, MESOS-2765, MESOS-5690, MESOS-5688, MESOS-5689,
> MESOS-4643, MESOS-4644, MESOS-5309
>
> On Sat, Jun 10, 2017 at 10:58 AM, Adam Bordelon 
> wrote:
>
> > +1 (binding) Good enough for me.
> >
> > Ran `make check` (or equivalent) on the Mesosphere internal Jenkins CI.
> > Lots of green (all tests passed) on Mac, CentOS7, Debian8, Fedora23 and
> > Ubuntu 12.04.
> > Three sets of yellow configs yielded 10 unique but mostly known
> > failing/flaky tests.
> > (Grey means untested)
> > [image: Inline image 1]
> >
> > * Ubuntu {14.04|16.04|16.10} - {Plain|SSL|CMake|Clang}
> >   PerfTest.Version (always) - https://issues.apache.org/
> > jira/browse/MESOS-7160
> >   ExamplesTest.PythonFramework (sometimes) - https://issues.apache.org/
> > jira/browse/MESOS-7218
> >
> > * Centos 6 - {Plain|SSL}
> >   DockerContainerizerTest.ROOT_DOCKER_LaunchWithPersistentVolumes -
> > https://issues.apache.org/jira/browse/MESOS-7510
> >
> > * Fedora 23 - Network_Isolator
> >   PortMappingIsolatorTest.ROOT_NC_HostToContainerUDP -
> > https://issues.apache.org/jira/browse/MESOS-5690
> >   PortMappingIsolatorTest.ROOT_ContainerICMPExternal -
> > https://issues.apache.org/jira/browse/MESOS-5689
> >   PortMappingIsolatorTest.ROOT_DNS - https://issues.apache.org/
> > jira/browse/MESOS-5688
> >   PortMappingIsolatorTest.ROOT_NC_SmallEgressLimit -
> > https://issues.apache.org/jira/browse/MESOS-5687
> >   PortMappingIsolatorTest.ROOT_NC_PortMappingStatistics - ?
> >   PortMappingMesosTest.CGROUPS_ROOT_RecoverMixedContainers - ?
> >   PortMappingMesosTest.CGROUPS_ROOT_RecoverMixedKnownAndUnKnownOrphans
> - ?
> >
> > Anybody have any ideas on the last three? Seems like these PortMapping
> > tests are generally in a bad shape, or the network isolator is seriously
> > broken. I'll file JIRAs.
> >
> > P.S. AgentAPIStreamingTest.AttachInputToNestedContainerSession Vinod saw
> > on ASF CI is flaky according to https://issues.apache.org/jira
> > /browse/MESOS-7159 (added the log gist link there)
> >
> > P.P.S.  CI results at https://jenkins.mesosphere.
> > com/service/jenkins/job/mesos/job/Mesos_CI-build/1215 for those with
> > access. We're still working on exposing our CI to the public. Waiting is.
> >
> >
> > On Thu, Jun 8, 2017 at 4:23 PM, Benjamin Mahler 
> > wrote:
> >
> >> +1 (binding)
> >>
> >> make check passed on macOS 10.12.4
> >>
> >> The ContentType/AgentAPIStreamingTest.AttachInputToNestedContainerSe
> ssion
> >> passed for me. Kevin, I captured the logs to the failed run vinod
> pointed
> >> to here:
> >>
> >> https://gist.github.com/bmahler/5ae340b4de3341f3c1f072250006dc64
> >>
> >> Does that look like a flaky test or a bug?
> >>
> >> On Thu, Jun 8, 2017 at 4:07 PM, Benjamin Mahler 
> >> wrote:
> >>
> >>> Vinod I think that's the getenv issue from: https://issues.apache.or
> >>> g/jira/browse/MESOS-6985
> >>>
> >>> On Wed, May 17, 2017 at 5:57 PM, Till Toenshoff 
> >>> wrote:
> >>>
> >>>> +1
> >>>>
> >>>> Ran it through DC/OS builds and integration tests;
> >>>> https://github.com/dcos/dcos/pull/1530 => all green
> >>>>
> >>>> On May 17, 2017, at 10:01 PM, Vinod Kone 
> wrote:
> >>>>
> >>>> Ran it on ASF CI and saw some issues.
> >>>>
> >>>> Segfault in "MasterTest.MultipleExecutors" in two builds [1]
> >>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/35/BUILDTOO

Re: [VOTE] Release Apache Mesos 0.18.0 (rc6)

[Adam Bordelon]

(Sending again, including user@ as well)
+1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2


On Wed, Apr 2, 2014 at 11:06 AM, Adam Bordelon  wrote:

> +1 Builds and checks on Linux Mint 12 (Ubuntu 12.10), gcc 4.7.2
>
>
> On Wed, Apr 2, 2014 at 10:02 AM, Niklas Nielsen  wrote:
>
>> +1, built and checked on OS X 10.9.2, clang-503.0.38 & Ubuntu 13.10, gcc
>> 4.8.1
>>
>> Niklas
>>
>>
>> On Tue, Apr 1, 2014 at 10:46 PM, Till Toenshoff  wrote:
>>
>> > +1 Builds and checks fine on OSX 10.9.2, clang 3.4 (Xcode5.1).
>> >
>> > On Apr 2, 2014, at 5:35 AM, Vinod Kone  wrote:
>> >
>> > > Hi all,
>> > >
>> > > Please vote on releasing the following candidate as Apache Mesos
>> 0.18.0.
>> > >
>> > >
>> > > 0.18.0 includes the following:
>> > >
>> >
>> 
>> > > * The primary feature of this release is a refactor of the isolation
>> > >   abstraction to make it easy to add pluggable
>> isolators/containerizers.
>> > >
>> > > 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=0.18.0-rc6
>> > >
>> >
>> 
>> > >
>> > > The candidate for Mesos 0.18.0 release is available at:
>> > >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz
>> > >
>> > > The tag to be voted on is 0.18.0-rc6:
>> > >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.0-rc6
>> > >
>> > > The MD5 checksum of the tarball can be found at:
>> > >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.md5
>> > >
>> > > The signature of the tarball can be found at:
>> > >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.18.0-rc6/mesos-0.18.0.tar.gz.asc
>> > >
>> > > The PGP key used to sign the release is here:
>> > > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> > >
>> > > The JAR is up in Maven in a staging repository here:
>> > >
>> https://repository.apache.org/content/repositories/orgapachemesos-1013
>> > >
>> > > Please vote on releasing this package as Apache Mesos 0.18.0!
>> > >
>> > > The vote is open until Fri Apr  4 20:29:44 PDT 2014 and passes if a
>> > majority of at least 3 +1 PMC votes are cast.
>> > >
>> > > [ ] +1 Release this package as Apache Mesos 0.18.0
>> > > [ ] -1 Do not release this package because ...
>> > >
>> > > Thanks,
>> > >
>> >
>>
>
>

Re: [MESOS] 0.17 src tarball missed some libprocess header files

[Adam Bordelon]

Could be related to https://issues.apache.org/jira/browse/MESOS-1176 which
was fixed in 0.18.
"make distcheck fails when enabling c++11"
"This is because libprocess Makefile doesn't include c+11 specific headers."



On Thu, Apr 3, 2014 at 5:29 AM, Zuyu Zhang  wrote:

> Hi all,
>
> I found the third party libprocess in mesos-0.17.0.tar.gz missed some
> header files for c++11 supports. The problem is that Mesos seems not to use
> --with-cxx11 in the configure script, but the macro (__cplusplus >=
> 201103L, in defer.hpp, deferred.hpp, delay.hpp, dispatch.hpp, and
> executor.hpp under 3rdparty/libprocess/include/process) to detect c++11
> features.
>
> Therefore, ANY machines with the default CXX compiler supporting c++11,
> when building from 0.17 src tarball, would have the following build errors,
> no matter whether one specifies --with-cxx11:
>
> In file included from ../../../3rdparty/libprocess/src/statistics.cpp:10:
>
> ../../../3rdparty/libprocess/include/process/delay.hpp:2:10: fatal error:
> 'process/c++11/delay.hpp' file not found
>
> #include 
>
> ^
>
> In file included from ../../../3rdparty/libprocess/src/process.cpp:46:
>
> ../../../3rdparty/libprocess/include/process/defer.hpp:2:10: fatal error:
> 'process/c++11/defer.hpp' file not found
> #include 
>
>
> I quickly fixed this problem by copying the directory 
> 3rdparty/libprocess/include/process/c++
> from the Mesos git repo. But I think a better solutions would use
> --with-cxx11 to trigger the C++11 supports. Thank you!
>
> Best,
> Zuyu Zhang
>

Re: 0.18.1

[Adam Bordelon]

Perhaps commit db3b5ed86b7f5a8d10fd8fc3fd59eb6faec2fe20 for MESOS-979?


On Tue, Apr 15, 2014 at 11:19 AM, Vinod Kone  wrote:

>
>
>
> On Mon, Apr 14, 2014 at 10:10 PM, Vinod Kone  wrote:
>
>> Looks like I missed cherry-picking the fix for
>> https://issues.apache.org/jira/browse/MESOS-1045 into 0.18.0.
>>
>> So I would like to cut 0.18.1 with the cherry-pick. If there is any other
>> important fix that belongs to 0.18.* release but didn't make it into 0.18.0
>> please reply to this thread and I'll see if I can include it.
>>
>> Thanks,
>>
>> @vinodkone
>>
>
>

Re: What happens if a scheduler registers with a framework ID that hasn't been used in 48 hours?

[Adam Bordelon]

David, did you see Vinod's response to your (identical) question on dev@?
http://www.mail-archive.com/dev@mesos.apache.org/msg11634.html


On Thu, Apr 17, 2014 at 11:26 AM, David Greenberg wrote:

> I don't recall the exact timeout of framework IDs, but what I'm wondering
> is what happens if a scheduler tries to "failover", but the failover grace
> period has elapsed? Does it fail to register, or does it successfully
> register and all the old executors are just gone?
>
>

Re: DRF on Mesos

[Adam Bordelon]

Adding user@mesos.apache.org, in case anybody else (not necessarily named
'Adam') wants to chime in.

If I understand your example correctly, ETL (e.g. Hadoop) and Analytics
(e.g. Spark) are two different Mesos frameworks that can each run multiple
jobs consisting of many tasks. Client1 and Client2 are users submitting the
job requests to the Nginx frontend, which in turn submits the jobs to the
appropriate frameworks.
Right now, there is no way to specify per-user weights in Mesos itself,
such that Client1 is guaranteed 3x the resources of Client2, no matter
which framework. So that would have to be handled by each framework's
scheduler (this is why Mesos is known as a two-level scheduler), or perhaps
even by your Nginx frontend itself.

So from Mesos' perspective, you have two frameworks ETL and Analytics, and
when the Mesos master gets some available resources, it will offer them to
whichever framework is furthest below its weighted fair share. So, if there
are 100 cpus total, and each framework starts with no resources, and let's
assume offers are batched in groups of 5 cpus, then ETL's weighted share is
(0/100)/1 and Analytics' is (0/100)/3 so the first offer could go to
either. Let's assume it's Analytics first. Then:
ETL.share = 0, and Analytics.share = (5/100)/3 = 0.0167; next offer goes to
ETL
ETL.share = (5/100) = 0.05, and Analytics.share = 0.0167; next offer goes
to Analytics
ETL.share = 0.05, and Analytics.share = (10/100)/3 = 0.033; next offer goes
to Analytics, etc.
Once an offer goes to a framework (e.g. Analytics), it's up to the
framework to decide which task(s)/job/user/client to give that offer to. We
currently don't have any base scheduler that you can inherit from to get
that kind of functionality, but it's certainly the kind of feature that
many would find useful. Perhaps a worthy addition to
Marathon/Aurora/Chronos?

Or we could make the sharing per-task/job-user first-class in Mesos as I
described in the other thread I referenced.
Anybody else have other thoughts/suggestions?


On Mon, Apr 14, 2014 at 6:32 AM, Adam Rosenberger <
adam.rosenberg...@gmail.com> wrote:

> Hey Adam,
>
> Thanks for the detailed info, that is helpful.
>
> Here is a simple use case:
>
> The application I work on is a multi tenant financial application, with a
> web based interface fronted by an nginx cluster. On the backend there is a
> large compute cluster for processing. There are several frameworks in the
> Mesos nomenclature, but for our purposes I think two would suffice.
>
> 1) ETL jobs for raw client data
> 2) Analytics jobs for generating reports on client data
>
> Both of those are run across the compute cluster due to volume of data and
> the problems ranging from embarrassingly parallel to somewhat
> parallelizable. As such the Mesos DRF makes perfect sense to declare those
> top level frameworks and provide weights (e.g. make Analytics 3:1 to ETL).
>
> However what I am struggling with is the multi tenancy of the application.
>
> Say we have 100 total CPUs on the cluster and all jobs require the same
> amount of [infinitely available] RAM, just to focus on CPU contention.
>
> If two competing requests come in for say
> - ETL: 40 CPUs
> - Analytics: 80 CPUs
>
> Then the Mesos allocator should take care of that for me.
>
> But as I understand the Executor / Scheduler architecture, in each Nginx
> server, I would have to keep a memory-based queue of jobs that come from
> the HTTP requests. Then on resource offers, I would be able to drain the
> queue in one or more shots with the jobs for Mesos.
>
> Expanding on that, now assume we have Client1 and Client2 both submitting
> ETL and Analytics jobs at the same time.
> - Client1 ETL: 50 CPUs
> - Client1 Analytics: 100 CPUs
> - Client2 ETL: 10 CPUs
> - Client2 Analytics: 20 CPUS
>
> If those requests all routed into the same Nginx server and I just keep a
> memory based queue of requests to submit to Mesos, it looks to me like
> Client1 ETL and Analytics would be subject to allocation policy which is
> great, but I would starve Client2 ... ClientN if a large job(s) arrived
> first.
>
> What I was hoping for was some way to submit say all ETL requests when a
> resource offer occurs and have some sort of second-level allocation policy
> to try some sort of fair share or priority based scheduling for the
> different clients.
>
> If I am off the mark on my understanding of the Mesos internals please do
> let me know. Thanks again.
>
> Adam
>
>
> On Mon, Apr 14, 2014 at 5:24 AM, Adam Bordelon  wrote:
>
>> Hi AdamR,
>>
>> It is certainly possible to specify resource allocation weights for
>> frameworks (or groups of frameworks), using the --weights and --roles
>> parameters to the m

Re: External Containererization API

[Adam Bordelon]

Also see https://gist.github.com/solidsnack/10944095 for SolidSnack's
getting-started-with-deimos if you want to try out Deimos (uses
Mesosphere's custom branch including r/17567)


On Wed, Apr 23, 2014 at 4:08 PM, Niklas Nielsen wrote:

> Hey Diptanu,
>
> MESOS-816 (and dependent patches) are still in the works but getting close
> to land. These reviews (https://reviews.apache.org/r/17567/ and
> https://reviews.apache.org/r/20080/) are (more or less) the last two
> outstanding pieces. The first external containerizer which use the new API
> can be found here: https://github.com/mesosphere/deimos
>
> Are you writing a new isolator in the context of the old isolation
> architecture, or targeted the new containerizer API?
>
> Cheers,
> Niklas
>
>
>
> On 23 April 2014 15:59, Diptanu Choudhury  wrote:
>
>> Hi,
>>
>> With Mesos 18 release, has support for passing ContainerInfo[per
>> MESOS-816] to slaves etc been released in the Java API?
>>
>> I am working on a docker isolator right now, and the only way I can pass
>> information to the executor right now is via the executor data. I am
>> wondering if Mesos 18 had anything to offer around that? I see a
>> ContainerID protobuf message but not sure what that is for.
>>
>> --
>> Thanks,
>> Diptanu Choudhury
>> Web - www.linkedin.com/in/diptanu
>> Twitter - @diptanu 
>>
>
>

Re: Questions about mesos-storm

[Adam Bordelon]

Chengwei,

Rather than an internal http server, you could also point the
mesos.executor.uri to an ftp or hdfs uri if you prefer.

-Adam-


On Mon, Apr 28, 2014 at 5:51 PM, Chengwei Yang
wrote:

> On Mon, Apr 28, 2014 at 04:15:25PM +0200, Tomas Barton wrote:
> > Hi Chengwei,
> >
> >
> > | 1. Is it necessary to deploy storm nimbus on the mesos master node?
> >
> > Yes, basically Nimbus runs as Mesos framework (inside Mesos master), if
> Mesos
> > master dies, it should start automatically on a different node.
> > It's not a standard Nimbus, it's MesosNimbus (Mesos framework):
> > code might look this (it's slightly outdated version):
> >
> https://github.com/nathanmarz/storm-mesos/blob/master/src/jvm/storm/mesos/
> > MesosNimbus.java
>
> Thanks!
>
> >
> >
> > | 2. How to deploy storm supervisor node?
> >
> > No need to do that. MesosNimbus will find resources and will run
> supervisor
> > process when a topology is submitted.
>
> Thank you, I saw that mesos.executor.uri set to the storm-mesos tarball,
> however, my VM can not access external network, so I'll verify that by
> setup a internal http server.
>
> --
> Thanks,
> Chengwei
> >
> > Tomas
> >
> > On 28 April 2014 03:49, Chengwei Yang 
> wrote:
> >
> > Hi List,
> >
> > I found mesosphere has a good page
> > http://mesosphere.io/learn/run-storm-on-mesos/ to guide user setup a
> > mesos-storm cluster.
> >
> > However, I found myself several questions about that guide.
> >
> > 1. Is it necessary to deploy storm nimbus on the mesos master node?
> >
> > The guide only says about deploy storm nimbus on the mesos master
> node.
> >
> > But I think it's fine to deploy storm nimbus on a different node. Am
> I
> > right?
> >
> > 2. How to deploy storm supervisor node?
> >
> > The guide doesn't say anything about deploy supervisor node, from
> that
> > guide, I see superviosr node deploy on-demand when a topology
> submitted?
> > Does mesos-storm do such cool stuff?
> >
> > If not, we need deploy supervisor in all mesos nodes?
> >
> > --
> > Thanks,
> > Chengwei
> >
> >
>

Re: how does the web UI get sandbox logs?

[Adam Bordelon]

>> Does each slave expose a webserver ...?
Yes. Each slave hosts a webserver not just for the sandbox, but also for
the slave's own webUI and RESTful API
For example, a particular slave's webUI (forwarded through master) can be
reached at:
http://localhost:5050/#/slaves/201405120912-16777343-5050-23673-0


On Thu, May 8, 2014 at 9:21 AM, Dick Davies  wrote:

> I've found the sandbox logs to be very useful in debugging
> misbehaving frameworks, typos, etc.  - the usual n00b stuff I suppose.
>
> I've got a vagrant stack running quite nicely. If i port forward I can
> view marathon and mesos UIs nicely from my host, but I can't get
> the sandbox logs because 'slaveN' isn't resolving from outside the
> Vagrant stack.
>
> I was a bit surprised because I didn't expect to need to reach the
> slaves directly.
>
> Does each slave expose a webserver to serve up
> sandbox logs or something? Just trying to work out how/if I can
> map things so that UI can be tunnelled easily.
>

Re: Max Share on Mesos Frameworks

[Adam Bordelon]

Hi Diptanu,

If you are referring to the "Max Share" column for frameworks in the web
ui, that is not a configuration parameter determining how many resources to
offer to a framework. It is rather just the max(cpu_share, mem_share) where
each share is the percentage of total resources currently in use by that
framework. A better descriptor for that column might be "Dominant Resource
Share".

If you do want to specify the share of resources offered to each framework,
you should look into the 'roles' and 'weights' parameters from
`mesos-master --help`. For example, you could specify that frameworks of
the "high priority" role deserve double the resource share of normal
frameworks, and that frameworks with the "low priority" should only get
half as many resources as normal frameworks.

Hope that helps,
-Adam-


On Mon, May 12, 2014 at 11:40 PM, Diptanu Choudhury wrote:

> Hi,
>
> Sorry if this is already answered somewhere in the docs, couldn't find
> anything. What does the Max share percentage for a framework mean? Is this
> something which would determine the share of offers which will be made to a
> framework if there are more than one running and if so is it something that
> can be configured programmatically.
>
> --
> Thanks,
> Diptanu Choudhury
> Web - www.linkedin.com/in/diptanu
> Twitter - @diptanu 
>

Re: Question on resource offers and framework failover

[Adam Bordelon]

Correct, Sharma. I don't think this is documented anywhere yet, but it
would be a good Mesos FAQ topic.
When the master notices that the framework has exited or is deactivated, it
disables the framework in the allocator so no new offers will be made to
that framework, and removes any outstanding offers (but does not send a
RescindResourceOfferMessage to the framework, since the framework is
presumably failing over). When a framework reregisters, it is reactivated
in the allocator and will start receiving new offers again.
If you were to try to persist the 'ephemeral' offers to another framework
instance, and call launchTasks with one of the old offers, the master will
respond with TASK_LOST ("Task launched with invalid offers"), since the
master no longer knows about that offer. So don't bother trying. :)
Already running tasks (used offers) continue running, unless the framework
failover timeout is exceeded.


On Mon, May 12, 2014 at 5:38 PM, Sharma Podila  wrote:

> My understanding is that when a framework fails over (either new instance
> starts after previous one fails, or the same instance restarts), Mesos
> master would automatically cancel any unused offers it had given to the
> previous framework instance. This is a good thing. Can someone confirm this
> to be the case? Is such an expectation documented somewhere? I did look at
> master.cpp and I hope I interpreted it right.
>
> Effectively then, the offers are 'ephemeral' and don't need to be
> persisted by the framework scheduler to pass along to another of its
> instance that may failover as the leader.
>
> Thank you.
>
> Sharma
>
>

Re: how does the web UI get sandbox logs?

[Adam Bordelon]

mesos-slave --hostname="foo"
"The hostname the slave should report."
"If left unset, system hostname will be used (recommended)."


On Tue, May 13, 2014 at 8:41 AM, Mike Milner  wrote:

> I just ran into something similar myself with mesos on EC2. I can reach
> the master just fine using the master's public dns name but when I go to
> the sandbox it's trying to connect to the slaves private internal DNS name.
>
> Is there a configuration option on the slave to manually specify the
> hostname that should be used in the web UI? I couldn't find anything on
> http://mesos.apache.org/documentation/latest/configuration/
>
> Thanks!
> Mike
>
>
> On Mon, May 12, 2014 at 4:27 PM, Ross Allen  wrote:
>
>> For example, a particular slave's webUI (forwarded through master) can be
>>> reached at:
>>> http://localhost:5050/#/slaves/201405120912-16777343-5050-23673-0
>>
>>
>>  Though it looks like the requests are being proxied through the master,
>> your browser is talking directly to the slave for any slave data. Your
>> browser first gets HTML, CSS, and JavaScript from the master and then sends
>> requests directly to the slave's webserver via JSONP for any slave data
>> shown in the UI.
>>
>> Ross Allen
>> r...@mesosphere.io
>>
>>
>> On 12 May 2014 09:21, Adam Bordelon  wrote:
>>
>>> >> Does each slave expose a webserver ...?
>>> Yes. Each slave hosts a webserver not just for the sandbox, but also for
>>> the slave's own webUI and RESTful API
>>> For example, a particular slave's webUI (forwarded through master) can
>>> be reached at:
>>> http://localhost:5050/#/slaves/201405120912-16777343-5050-23673-0
>>>
>>>
>>> On Thu, May 8, 2014 at 9:21 AM, Dick Davies wrote:
>>>
>>>> I've found the sandbox logs to be very useful in debugging
>>>> misbehaving frameworks, typos, etc.  - the usual n00b stuff I suppose.
>>>>
>>>> I've got a vagrant stack running quite nicely. If i port forward I can
>>>> view marathon and mesos UIs nicely from my host, but I can't get
>>>> the sandbox logs because 'slaveN' isn't resolving from outside the
>>>> Vagrant stack.
>>>>
>>>> I was a bit surprised because I didn't expect to need to reach the
>>>> slaves directly.
>>>>
>>>> Does each slave expose a webserver to serve up
>>>> sandbox logs or something? Just trying to work out how/if I can
>>>> map things so that UI can be tunnelled easily.
>>>>
>>>
>>>
>>
>

Re: How can I ask mesos cluster to reload configuration?

[Adam Bordelon]

Chengwei,

You can restart the leading master (with new roles/config), and running
frameworks/slaves will re-register with it. Tasks will keep running. You
probably want to restart the non-leading masters first with the new config,
so that it will be picked up on HA failover.
You can also restart the slave processes with the new resource-roles config
and running tasks will continue running, as long as you have slave
checkpointing enabled.
You also need to restart the framework-scheduler so that it can reregister
with the new role (in its FrameworkInfo), and get new offers appropriate
for that role. Tasks will keep running.

You need to restart the master (with new roles config) before restarting
the framework (with new role in its FrameworkInfo), or else the framework
will fail to reregister ("Role 'foo' is not valid."). I would recommend
restarting the master first, then the slave(s), then the framework.
Currently running tasks will continue running, regardless of role
configuration. The new role(s) will only apply to new resource offers.

Hope that helps,
-Adam-


On Tue, May 13, 2014 at 2:31 PM, Vinod Kone  wrote:

> Hey Chengwei,
>
> Mesos doesn't allow online update of its configuration. The only
> exception, so far, has been the VLOG  level.
>
> To update resources, you should roll the slave with new flags.
>
>
> On Sun, May 11, 2014 at 12:02 AM, Chengwei Yang <
> chengwei.yang...@gmail.com> wrote:
>
>> Hi List,
>>
>> Generally I have a question: does mesos cluster can reload configuration
>> on the fly? Without side-effect to on-top frameworks, jobs?
>>
>> I have read the upgrad guide,
>> http://mesos.apache.org/documentation/latest/upgrades/
>>
>> and slave recovery guide,
>> http://mesos.apache.org/documentation/latest/slave-recovery/
>>
>> However, I didn't see any statement says about does the upgrade hurt
>> on-top frameworks, jobs.
>>
>> My situation is: I have a mesos 0.16 cluster up and running, some
>> frameworks and jobs running, and I want to add another framework, and
>> like to add a dedicate role for it, so change should made to mesos
>> master, and resolve some resources for it, so change should made to
>> mesos slaves.
>>
>> Could I do this seamlessly? Thanks in advance!
>>
>> --
>> Thanks,
>> Chengwei
>>
>
>

Re: Log managment

[Adam Bordelon]

Hi Damien,

Log rotation sounds like a reasonable request. Please file a JIRA for it,
and we can discuss details there.

Thanks,
-Adam-


On Wed, May 14, 2014 at 1:46 AM, Damien Hardy  wrote:

> Hello,
>
> Log in mesos are problematic for me so far.
> We are used to use log4j facility in java world that permit a lot of
> things.
>
> Mainly I would like log rotation (ideally with logrotate tool to be
> homogeneous with other things) without restarting processes because in
> my experience it looses history ( mesos 0.16.0 so far )
>
> Best regards,
>
> --
> Damien HARDY
> IT Infrastructure Architect
> Viadeo - 30 rue de la Victoire - 75009 Paris - France
> PGP : 45D7F89A
>
>

Re: [VOTE] Release Apache Mesos 0.18.2 (rc1)

[Adam Bordelon]

+1 make check passes on Linux Mint 16 (Ubuntu 13.10), gcc 4.8.1


On Wed, May 14, 2014 at 12:06 PM, Niklas Nielsen  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.18.2.
>
>
> 0.18.2 includes the following:
>
> 
> [MESOS-1313] - The executor bit is now essentially ignored with the 0.18.1
> fetcher implementation
>
>
> 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=0.18.2-rc1
>
> 
>
> The candidate for Mesos 0.18.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.18.2-rc1/mesos-0.18.2.tar.gz
>
> The tag to be voted on is 0.18.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.18.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.18.2-rc1/mesos-0.18.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.18.2-rc1/mesos-0.18.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1020
>
> Please vote on releasing this package as Apache Mesos 0.18.2!
>
> The vote is open until Sat May 17 12:04:39 PDT 2014 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.18.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Niklas
>

Re: HDFS on Mesos

[Adam Bordelon]

+dev@

I think it makes a lot of sense to run Distributed File Systems on top of
Mesos, whether that be HDFS, MapRFS, Lustre, BitTorrent, or whatever. HDFS
is very popular with Mesos users, and is currently supported as an executor
fetching protocol/source. I would love to see an HDFS framework for Mesos.
Below are my thoughts.

** Advantages:
+ Fault-tolerance/HA: Automatically restart failed NameNodes, always have
enough standbys.
+ Shared resources: Mesos can allocate/isolate resources for HDFS NN/DN
processes alongside other frameworks
+ Scaling: Easily scale up/down the number of DataNodes as the cluster grows

** Challenges:
Launching NameNode (NN) tasks:
- Need multiple NNs, for HA-standbys and/or federated NNs.
- Do we have to manually configure federated namespaces?
- Could we use the Mesos replicated log for NN-HA's edit log, instead of
NFS or the JournalNodes?

Launching DataNode (DN) tasks:
- DNs must be started with names of all(?) NNs, register/update with each.
Need a svc-discovery tool, or just start all NNs first, then start DNs with
known NNs? How to update when NNs move? Use ZK to track?

The Bootstrap problem:
- Where to fetch the NN/DN executors/tasks? Could use another HDFS cluster,
S3/HTTP/FTP, or pre-install the binaries on each slave.

Migrating an existing HDFS cluster:
- Is it possible to do a migration from raw HDFS to HDFS-on-Mesos without
moving the data?

Data Residency:
- Should we destroy the sandbox/hdfs-data when shutting down a DN?
- If starting DN on node that was previously running a DN, can/should we
try to revive the existing data?

Topology contraints:
- Must guarantee only one DN (per fwk) per slave, only one NN (per fwk) per
slave.
- Wouldn't want NNs (or replicated blocks?) to live on the same physical
node/rack. Could use attributes to express topology.

Kerberos integration:
- How to ensure that NN has access to the KDC and/or required
keytabs/credentials?



On Wed, Jun 25, 2014 at 6:17 AM, Vladimir Vivien 
wrote:

> +1 wondered about this.  Would love to hear pros/cons.
>
>
> On Wed, Jun 25, 2014 at 8:00 AM, Maxime Brugidou <
> maxime.brugi...@gmail.com> wrote:
>
>> Hi Mesos Community,
>>
>> I am a bit surprised to see that no one has done a framework to run HDFS
>> on top of Mesos directly since a lot of people seem to use HDFS in the
>> community. HDFS seems to be managed separately from Mesos (but will
>> probably run on the same machines). Is there any reason for that?
>>
>> My understanding is that using Mesos to manage all resources and having
>> HDFS on top of it makes much more sense (just like a FS runs inside an OS,
>> not on the side).
>>
>> Is it technical complexity? (we run HDFS and YARN with HA, journalnodes
>> and Kerberos Security and it is definitely a beast) Is it because no one
>> really feels the need for this since they are already running HDFS on the
>> side close to the hardware and don't want to waste time having it in Mesos?
>>
>> Best
>> Maxime
>>
>
>
>
> --
> Vladimir Vivien
>

Re: MesosCon program commitee notes, 6/26 and 6/19

[Adam Bordelon]

> Dave and Chris will be at OSCON and will try to get out the word there.
Mesosphere will also be presenting at OSCon, and we'll promote MesosCon as
well.
http://www.oscon.com/oscon2014/public/schedule/detail/34432
http://www.oscon.com/oscon2014/public/schedule/detail/34422


On Thu, Jun 26, 2014 at 2:53 PM, Dave Lester  wrote:

> Below are notes from the last two MesosCon program committee meetings.
>
> Dave
>
>
> 06/26/2014
>
> *Attendees*
> Dave Lester, Isabel Jimenez, Benjamin Hindman, Chris Aniszczyk
>
> *Attendee/Registration Update*
> As of last Friday, 23 MesosCon, 121 LinuxCon attendees who have MesosCon
> addon. Speakers have not yet registered. Registration is on a positive
> trajectory (~20 per week), and will likely sell out.
>
> *Outreach*
> Dave and Chris will be at OSCON and will try to get out the word there.
> Consensus among the committee was that registration is on the right track.
>
> *Sponsor Update*
> No new sponsors at this time.
>
> *Event Ideas / Enhancements*
> We discussed having a job board at the event to connect companies with
> developers who may be interested in opportunities.
>
>
> 06/19/2014
>
> *Attendees*
> Dave Lester, Vinod Kone, Matt Trifiro, Timothy St Clair, Benjamin Hindman,
> Chris Aniszczyk, Isabel Jimenez
>
> *Attendee/registration Update*
> As of last Friday, 15 MesosCon, 108 LinuxCon registrations who have
> MesosCon addon.
>
> Should an incentive be needed to encourage early registration, the program
> committee may consider raising the price of tickets at a later date,
> encouraging folks to register ahead of time. No immediate plans to do so.
>
> *Outreach*
> Made to Mesos meetup groups, as well as SF Cloud Computing meetup group.
>
> Discussion of including MesosCon in our email footers to help advertise
> the event and get the word out.
>
> *Sponsor Update*
> At least one unconfirmed sponsor in the works, will wait for future
> updates.
>

Re: n00b isolation docs?

[Adam Bordelon]

Hi Dick,

Sorry for the late reply, but I wanted to answer your question from the
last email.
If you are using the default Posix isolation, then there is no enforcement
on the actual cpu/memory usage of your tasks. Rather, it is only the
master's resource allocator that does its own resource accounting and
allocation based on the stated resources on the slaves and the stated
resources used by running/completed tasks. You will need to use cgroups
isolation to actually restrict your tasks from overstepping their
cpu-shares or memory limits.
If the tasks running on your slaves are reporting resource usage matching
the resource requirements you set in Marathon, then you're fortunate to
have chosen accurate requirements, but nothing in Mesos is enforcing these
limits.
Let us know how cgroups are working out for you. Are there any specific
setup/configuration steps that we could document better?

Cheers,
-Adam-


On Tue, Jun 10, 2014 at 12:37 PM, Dick Davies 
wrote:

> Thanks, I'd normally read code to figure this kind of thing out but
> C++ is one of the
> few languages I have no clue with.
>
> What I'll do then (I'm on RHEL) is install libcgroup, start cgconfig
> and see what happens
> with that new --isolation flag.
>
> Part of the reason I was asking is I wasn't clear that the tasks I'm
> sending out with RAM
> and CPU allocations on them are actually enforced out of the box - is
> that right?
>
> We're running Marathon and shipping out jobs with 256MbRAM/01.CPU
> requirements,
> and seems like the slaves are reporting used resources based on those
> numbers.
>
> I think it's a bit unlikely these random jobs are actually using
> exactly those resources,
> and so I wondered if we're enforcing it anywhere.
>
>
>
> On 9 June 2014 17:02, Jie Yu  wrote:
> > Hi Dick,
> >
> >>
> >> what croup isolation provides over stock posix / process isolation
> >
> >
> > Currently, mesos provides cpu and memory isolation through cgroups on
> Linux
> > boxes '--isolation=cgroups/cpu,cgroups/mem'
> >
> >> the configuration required to setup cgroups
> >
> >
> > If no other service on the host uses cgroup (no cgroup subsystems being
> > mounted), then it should be pretty simple because mesos will mount
> > corresponding subsystems for you. You can choose the root hierarchy using
> > the following slave flag:
> >
> > add(&Flags::cgroups_hierarchy,
> > "cgroups_hierarchy",
> > "The path to the cgroups hierarchy root\n",
> > "/sys/fs/cgroup");
> >
> > If some services on the host are using cgroup (e.g, systemd), then it
> > depends on how cgroups are mounted.
> >
> > - Jie
> >
> >
> >
> > On Mon, Jun 9, 2014 at 3:09 AM, Dick Davies 
> wrote:
> >>
> >> So we're running with default isolation (posix)
> >> and thinking about enabling cgroups (mesos 0.17.0
> >> right now but the upgrade to 0.18.2 was seamless
> >> in dev. so that'll probably happen too).
> >>
> >> I just need to justify the effort and extra complexity,
> >> so can someone explain briefly
> >>
> >> * what croup isolation provides over stock posix / process isolation
> >> * the configuration required to setup cgroups
> >>
> >> Thanks!
> >
> >
>

Re: Slave decomissioning

[Adam Bordelon]

Hi Maxime,

The slave decomissioning feature is in-progress. For updates, see
https://issues.apache.org/jira/browse/MESOS-1474 and its sub-JIRAs
MESOS-1475 and MESOS-1476
This includes "Provide a way for frameworks to be notified when resources
are requested to be relinquished. This gives the framework to proactively
move a task before it is forcibly killed. It also allows the automation of
operations like: "please drain these slaves within 1 hour.""

Hope that helps!
-Adam-


On Mon, Jun 30, 2014 at 1:44 PM, Maxime Brugidou 
wrote:

> hi,
>
> Is there any task status update that a scheduler can hook to when a slave
> will be decommissioned? Is there any process to decommission a slave?
>
> This is useful when you need to migrate data from the decommissioned
> slave. I am looking for a sort of status update for tasks running on the
> slave and the master shouldn't schedule any other task while
> decommissioning. The slave could be marked as OK for decommission if no
> tasks are running.
>
> Best,
> Maxime
>

Re: Passing a pointer to an Object in task Info

[Adam Bordelon]

The framework scheduler is expected to run on a separate machine from the
tasks/executors. If you want the executor to perform an action, then it
should be a method on the executor itself, or a separate task binary. On
the other hand, if you want the executor to cause the scheduler to do
something, you could either (a) trigger a scheduler action by sending back
a StatusUpdate, or (b) use sendFrameworkMessage to send a message back to
the scheduler, and the scheduler can act upon the frameworkMessage callback.


On Wed, Jul 30, 2014 at 10:34 AM, Sai Sagar  wrote:

> Hi Niklas,
>
> Thanks for the response.
>
> Actually I have an Instance of a framework running. The framework is in
> C++. I registered the framework with mesos. I am getting resource offers
> offered by Apache mesos. For getting resources, I sent the "this" pointer
> of the instance to the class which implements our mesos scheduler
> interface. I have launch the task taken from the "this" pointer.
>
> I am perplexed how to proceed. The instance of framework has no
> serialization implementation.
>
> My task is to carry the instance of framework to the executor and then
> call a method from the task data given in scheduler of mesos.
>
> J. Sai Sagar
> Associate Engineer,
> Innovation Labs
> Impetus - Bangalore
>
>
> On Wed, Jul 30, 2014 at 10:35 PM, Niklas Nielsen 
> wrote:
>
>> I am not sure I completely understand the issue. Just passing a pointer
>> won't work. The compiled protobuf code won't try to infer the size of the
>> object. Also it will go over the wire, so you can't reference memory on the
>> other node.
>> In one way or another, you need to serialize the object to a byte array.
>> How you interpret that on the other end is different thing; here you should
>> be able to reconstruct the object and have the implementations handy on the
>> receiver side.
>>
>> // Sender
>> Obj a;
>> task.set_data(a.serialize())
>>
>> // Receiver
>> Obj b;
>> b.deserialize(task.data())
>> b.foobar(); // Call your method - the implementation need to be known by
>> the receiver.
>>
>> Did I misunderstand your question?
>>
>> Niklas
>>
>>
>> On 30 July 2014 03:43, Sai Sagar  wrote:
>>
>>> Hi all,
>>>
>>> I want to pass a pointer to an object in Task Information like we do in
>>> task.set_data("some string").
>>> In executor, I want to call a method of the object with some parameters
>>> sent along with pointer to object in task information. Can some one please
>>> guide me on this?
>>>
>>>
>>> Best Regards,
>>>
>>> J. Sai Sagar
>>> Software Engineer,
>>> Innovation Labs
>>> Impetus - Bangalore
>>>
>>>
>>
>>
>

Re: mesos build errors

[Adam Bordelon]

For scheduling workflows of batch jobs, I would recommend looking into the
Chronos framework for Mesos:
https://github.com/airbnb/chronos
http://mesosphere.io/learn/run-chronos-on-mesos/
http://nerds.airbnb.com/introducing-chronos/


On Thu, Jul 24, 2014 at 4:58 AM, Itamar Ostricher 
wrote:

> Not written in MPI. Each task is a stand-alone execution of a binary
> program that takes the 1-2 data file paths as parameters (GCS paths), with
> the output stored in another GCS file (path as flag).
> Different tasks do not need to communicate with others. Tasks only talk
> with GCS to read and write their data.
> The biggest bottleneck (for most tasks) is CPU. Few of the tasks do little
> processing, so in these cases the bottleneck is GCS latency.
>
> Our current solution is to run N services on each machine (N = number of
> cores on the machine), with the main Python script sending commands to
> available services (using sockets).
> We are not happy with this solution because it requires us to deal with
> too many low-level details, like tracking the status of the services,
> restarting lost tasks, collecting logs, etc.
>
>
> On Thu, Jul 24, 2014 at 11:37 AM, Tomas Barton 
> wrote:
>
>> Depends on the nature of your tasks. Your code is written in MPI? You
>> tasks needs to communicate with others? One task will operate on all files,
>> some subset, or just on file? You might have:
>>  - one task per machine running on as many cores as possible
>>  - many smaller tasks starting in a dynamic manner depending on the
>> data
>>
>> What is the biggest bottleneck you have? disk read/write, network, CPU,
>> memory?
>>
>> Writing own framework is possible, if you can take advantage of some
>> problem specific property.
>>
>>
>> On 24 July 2014 07:34, Itamar Ostricher  wrote:
>>
>>> many: we have a processing pipeline with ~10 stages (one C++ program per
>>> stage usually), batch processing (almost-)all pairs of files in the
>>> dataset. the dataset contains >10K files at the moment, so a couple of
>>> hundreds of millions of program executions would be my definition for
>>> "many" in this case :-)
>>>
>>> I'll start with few machines with deploy scripts and a small subset of
>>> the dataset just to get the hang of it.
>>> It's a bit difficult to comprehend the stack, with all the possible
>>> options and combinations, though.
>>> If I have a main Python script that generates all the processing
>>> pipeline commands (that can be simply executed via shell), should I use a
>>> specific framework (like Hydra)? Or maybe use raw mesos? Or maybe I should
>>> write my own framework?
>>>
>>>
>>> On Wed, Jul 23, 2014 at 2:25 PM, Tomas Barton 
>>> wrote:
>>>
 Define many :) If you want to use some provisioning tools like Puppet,
 Chef, Ansible... there are quite a few modules to do this job:

 http://mesosphere.io/learn/#tools

 If you have only a few machines, you might be fine with deploy scripts.

 An example of MPI framework is here:

 https://github.com/mesosphere/mesos-hydra




 On 23 July 2014 12:26, Itamar Ostricher  wrote:

> Thanks Tomas.
>
> ldconfig didn't change anything. make still failed.
>
>  But the Debian packaged installed like a charm, so I'm good :-)
> Now I just need to figure out how to use it...
> (going to start with [1], unless anyone chimes in with a better
> recommended starting point for a mesos-newbie who is trying to set up a
> cluster of GCE instances in order to distribute execution of *many* C++
> programs working on a large dataset that is currently stored in Google
> Cloud Storage.)
>
> [1] http://mesos.apache.org/documentation/latest/deploy-scripts/
>
>
> On Wed, Jul 23, 2014 at 11:55 AM, Tomas Barton  > wrote:
>
>> Hi,
>>
>> that's quite strange. Try to run
>>
>> ldconfig
>>
>> and then again make.
>>
>> You can find binary packages for Debian here:
>> http://mesosphere.io/downloads/
>>
>> Tomas
>>
>>
>> On 23 July 2014 10:09, Itamar Ostricher  wrote:
>>
>>> Hi,
>>>
>>> I'm trying to do a clean build of mesos for the 0.19.0 tarball.
>>> I was following the instructions from
>>> http://mesos.apache.org/gettingstarted/ step by step. Got to
>>> running `make`, which ran for quite a while, and exited with errors (see
>>> the end of the output below).
>>>
>>> Extra env info: I'm trying to do this build on a 64-bit Debian GCE
>>> instance:
>>> itamar@mesos-test-1:/tmp/mesos-0.19.0/build$ uname -a
>>> Linux mesos-test-1 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64
>>> GNU/Linux
>>>
>>> Assistance will be much appreciated!
>>> Alternatively, I don't mind using precompiled binaries, if anyone
>>> can point me in the direction of such binaries for the GCE environment I
>>> described :-)
>>>
>>> tail of make output:

Re: mesos build errors

[Adam Bordelon]

Hi Nayeem,

You could use Deimos to set a default Docker image to push your tasks into,
but Chronos currently lacks the configuration interface necessary to run a
specific Docker container as a job.
It shouldn't be difficult to add, since the support is already there in
Mesos. I filed https://github.com/airbnb/chronos/issues/241 to track the
issue.

Thanks,
-Adam-




On Fri, Aug 1, 2014 at 7:34 PM, Nayeem Syed  wrote:

> chronos looks interesting, but we have tasks we need to do regularly that
> are part of a rails project. currently we are running it using sidekiq
> workers + clock using docker via marathon.
>
> how would I be able to run it on Chronos as I cant see any special way of
> running a task within a docker container? Ideally it would have been good
> to have some docker containers on standby that just runs the task at the
> specified time..
>
>
> On Fri, Aug 1, 2014 at 12:00 PM, Adam Bordelon  wrote:
>
>> For scheduling workflows of batch jobs, I would recommend looking into
>> the Chronos framework for Mesos:
>> https://github.com/airbnb/chronos
>> http://mesosphere.io/learn/run-chronos-on-mesos/
>> http://nerds.airbnb.com/introducing-chronos/
>>
>>
>> On Thu, Jul 24, 2014 at 4:58 AM, Itamar Ostricher 
>> wrote:
>>
>>> Not written in MPI. Each task is a stand-alone execution of a binary
>>> program that takes the 1-2 data file paths as parameters (GCS paths), with
>>> the output stored in another GCS file (path as flag).
>>> Different tasks do not need to communicate with others. Tasks only talk
>>> with GCS to read and write their data.
>>> The biggest bottleneck (for most tasks) is CPU. Few of the tasks do
>>> little processing, so in these cases the bottleneck is GCS latency.
>>>
>>> Our current solution is to run N services on each machine (N = number of
>>> cores on the machine), with the main Python script sending commands to
>>> available services (using sockets).
>>> We are not happy with this solution because it requires us to deal with
>>> too many low-level details, like tracking the status of the services,
>>> restarting lost tasks, collecting logs, etc.
>>>
>>>
>>> On Thu, Jul 24, 2014 at 11:37 AM, Tomas Barton 
>>> wrote:
>>>
>>>> Depends on the nature of your tasks. Your code is written in MPI? You
>>>> tasks needs to communicate with others? One task will operate on all files,
>>>> some subset, or just on file? You might have:
>>>>  - one task per machine running on as many cores as possible
>>>>  - many smaller tasks starting in a dynamic manner depending on the
>>>> data
>>>>
>>>> What is the biggest bottleneck you have? disk read/write, network, CPU,
>>>> memory?
>>>>
>>>> Writing own framework is possible, if you can take advantage of some
>>>> problem specific property.
>>>>
>>>>
>>>> On 24 July 2014 07:34, Itamar Ostricher  wrote:
>>>>
>>>>> many: we have a processing pipeline with ~10 stages (one C++ program
>>>>> per stage usually), batch processing (almost-)all pairs of files in the
>>>>> dataset. the dataset contains >10K files at the moment, so a couple of
>>>>> hundreds of millions of program executions would be my definition for
>>>>> "many" in this case :-)
>>>>>
>>>>> I'll start with few machines with deploy scripts and a small subset of
>>>>> the dataset just to get the hang of it.
>>>>> It's a bit difficult to comprehend the stack, with all the possible
>>>>> options and combinations, though.
>>>>> If I have a main Python script that generates all the processing
>>>>> pipeline commands (that can be simply executed via shell), should I use a
>>>>> specific framework (like Hydra)? Or maybe use raw mesos? Or maybe I should
>>>>> write my own framework?
>>>>>
>>>>>
>>>>> On Wed, Jul 23, 2014 at 2:25 PM, Tomas Barton 
>>>>> wrote:
>>>>>
>>>>>> Define many :) If you want to use some provisioning tools like
>>>>>> Puppet, Chef, Ansible... there are quite a few modules to do this job:
>>>>>>
>>>>>> http://mesosphere.io/learn/#tools
>>>>>>
>>>>>> If you have only a few machines, you might be fine with deploy
>>>>>> scripts.
>>>>>>
>>>>>> A

Re: Spark scheduler receives no offers after some time

[Adam Bordelon]

Seems strange that you only have 2MB of allocatable memory on your slave
("total allocatable: cpus(*):2; mem(*):2;").
Try bumping that up to something like 2GB ("mem(*):2048") and I bet you'll
see more tasks able to run.
Even the default executor (no task) needs 32MB, so you won't be able to do
much with a mesos slave that has <64MB memory.
Are you explicitly setting a --resources flag on your slave? If not, do you
only have tiny VMs available for the slaves?


On Thu, Aug 7, 2014 at 7:03 AM, Martin Weindel 
wrote:

> I'm using Apache Mesos 0.19.0 together with Apache Spark 1.0.2 on a three
> node cluster.
>
> When using the fine-grained task scheduling mode of Spark, I reproducably
> see some kind of dead lock on high load.
> If multiple jobs are running, after some time the jobs do not submit any
> tasks anymore.
>
> I have added some more log output in the Scheduler implementation of Spark
> and it looks as if Mesos does not make any offers anymore, although there
> are allocatable resources.
>
> Below is the log from Mesos. The last task is normally finished, the
> resources recovered, the filters are removed, but the log shows no "sending
> ... offers to framework" entries after this timepoint.
> I have tried to wake up the offers with a reviveOffers call I have added
> to the Spark code, but with no effect.
> The "Resources" section on the Mesos web UI shows all CPUs as idle, none
> is used or offered.
>
> If I kill all jobs but one, this last job continues and finishes normally.
>
> Is this a bug?
>
> Thanks,
> Martin
>
> I0807 15:17:54.605695 15727 master.cpp:2933] Sending 1 offers to framework 
> 20140717-090825-308511242-5050-15711-0044
> I0807 15:17:54.615705 15732 master.cpp:1889] Processing reply for offers: [ 
> 20140717-090825-308511242-5050-15711-2132 ] on slave 
> 20140717-090821-325288458-5050-2360-1 at slave(1)@10.130.99.20:5051 
> (ustst020-cep-node3.usu.usu.grp) for framework 
> 20140717-090825-308511242-5050-15711-0044
> I0807 15:17:54.615897 15732 master.hpp:655] Adding task 1 with resources 
> cpus(*):1; mem(*):1 on slave 20140717-090821-325288458-5050-2360-1 
> (ustst020-cep-node3.usu.usu.grp)
> I0807 15:17:54.616029 15732 master.cpp:3111] Launching task 1 of framework 
> 20140717-090825-308511242-5050-15711-0044 with resources cpus(*):1; mem(*):1 
> on slave 20140717-090821-325288458-5050-2360-1 at slave(1)@10.130.99.20:5051 
> (ustst020-cep-node3.usu.usu.grp)
> I0807 15:17:54.616325 15732 hierarchical_allocator_process.hpp:589] Framework 
> 20140717-090825-308511242-5050-15711-0044 filtered slave 
> 20140717-090821-325288458-5050-2360-1 for 8secs
> I0807 15:17:58.324476 15728 master.cpp:2628] Status update TASK_RUNNING 
> (UUID: ec5ecf90-7313-4bf1-af9e-b5f6e35189f7) for task 1 of framework 
> 20140717-090825-308511242-5050-15711-0044 from slave 
> 20140717-090821-325288458-5050-2360-1 at slave(1)@10.130.99.20:5051 
> (ustst020-cep-node3.usu.usu.grp)
> I0807 15:17:58.326279 15726 master.cpp:1988] Reviving offers for framework 
> 20140717-090825-308511242-5050-15711-0044
> I0807 15:17:58.326406 15732 hierarchical_allocator_process.hpp:660] Removed 
> filters for framework 20140717-090825-308511242-5050-15711-0044
> I0807 15:18:00.993798 15726 master.cpp:2628] Status update TASK_FINISHED 
> (UUID: ef7a4dfd-c403-483a-a6a7-c2cd995aa64e) for task 1 of framework 
> 20140717-090825-308511242-5050-15711-0044 from slave 
> 20140717-090821-325288458-5050-2360-1 at slave(1)@10.130.99.20:5051 
> (ustst020-cep-node3.usu.usu.grp)
> I0807 15:18:00.994935 15726 master.hpp:673] Removing task 1 with resources 
> cpus(*):1; mem(*):1 on slave 20140717-090821-325288458-5050-2360-1 
> (ustst020-cep-node3.usu.usu.grp)
> I0807 15:18:00.995511 15726 master.cpp:1988] Reviving offers for framework 
> 20140717-090825-308511242-5050-15711-0044
> I0807 15:18:00.995599 15725 hierarchical_allocator_process.hpp:636] Recovered 
> cpus(*):1; mem(*):1 (total allocatable: cpus(*):2; mem(*):2; disk(*):12526; 
> ports(*):[31000-32000]) on slave 20140717-090821-325288458-5050-2360-1 from 
> framework 20140717-090825-308511242-5050-15711-0044
> I0807 15:18:00.995846 15725 hierarchical_allocator_process.hpp:660] Removed 
> filters for framework 20140717-090825-308511242-5050-15711-0044
> I0807 15:18:01.055794 15730 master.cpp:1988] Reviving offers for framework 
> 20140717-090825-308511242-5050-15711-0044
> I0807 15:18:01.055982 15730 hierarchical_allocator_process.hpp:660] Removed 
> filters for framework 20140717-090825-308511242-5050-15711-0044
>
>

Re: Alternate HDFS Filesystems + Hadoop on Mesos

[Adam Bordelon]

Can't you just use the hdfs:// protocol for maprfs? That should work just
fine.


On Fri, Aug 15, 2014 at 2:50 PM, John Omernik  wrote:

> Thanks all.
>
> I realized MapR has a work around for me that I will try soon in that I
> have MapR fs NFS mounted on each node, I.e. I should be able to get the tar
> from there.
>
> That said, perhaps someone with better coding skills than me could provide
> an env variable where a user could provide the HDFS prefixes to try. I know
> we did that with the tachyon project and it works well for other HDFS
> compatible fs implementations, perhaps that would work here?  Hard coding a
> pluggable system seems like a long term issue that will keep coming up.
> On Aug 15, 2014 4:02 PM, "Tim St Clair"  wrote:
>
>> The uri doesn't currently start with any of the known types (at least on
>> 1st grok).
>> You could redirect via a proxy that does the job for you.
>>
>> | if you had some fuse mount that would work too.
>>
>> Cheers,
>> Tim
>>
>> --
>>
>> *From: *"John Omernik" 
>> *To: *user@mesos.apache.org
>> *Sent: *Friday, August 15, 2014 3:55:02 PM
>> *Subject: *Alternate HDFS Filesystems + Hadoop on Mesos
>>
>> I am on a wonderful journey trying to get hadoop on Mesos working with
>> MapR.   I feel like I am close, but when the slaves try to run the packaged
>> Hadoop, I get the error below.  The odd thing is,  I KNOW I got Spark
>> running on Mesos pulling both data and the packages from MapRFS.  So I am
>> confused why there is and issue with the fetcher.cpp here. Granted, when I
>> got spark working, it was on 0.19.0, and I am trying a "fresh" version from
>> git (0.20.0?) that I just pulled today. I am not sure if that work, but
>> when I have more time I will try spark again.
>>
>> Any thoughts on this error? Thanks.
>>
>>
>>
>>
>> Error:
>>
>>
>>
>> WARNING: Logging before InitGoogleLogging() is written to STDERR
>> I0815 15:48:35.446071 20636 fetcher.cpp:76] Fetching URI 
>> 'maprfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz'
>> E0815 15:48:35.446184 20636 fetcher.cpp:161] A relative path was passed for 
>> the resource but the environment variable MESOS_FRAMEWORKS_HOME is not set. 
>> Please either specify this config option or avoid using a relative path
>> Failed to fetch: maprfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz
>> Failed to synchronize with slave (it's probably exited)
>>
>>
>>
>>
>> --
>> Cheers,
>> Timothy St. Clair
>> Red Hat Inc.
>>
>

Re: mesos scheduling

[Adam Bordelon]

Mesos uses a fair-sharing algorithm[1] to ensure that each framework
registered with Mesos is ensured its fair share of resources. If you want
more control over the groupings and weights of different frameworks, check
out the roles and weights parameters: mesos-master --roles="services,batch"
and --weights="services=2,batch=1" as described at
http://mesosphere.io/docs/mesos/deep-dive/mesos-master/

Mesos uses these algorithms and parameters to decide which framework gets
the next offer, so it won't affect already running tasks if one framework
is already hogging the cluster when you start a new framework. But if you
start killing tasks from the over-provisioned framework, those resources
will be offered to the new framework(s) until it reaches its fair share.

[1] http://static.usenix.org/event/nsdi11/tech/full_papers/Ghodsi.pdf


On Sun, Aug 17, 2014 at 7:06 PM, Jun Feng Liu  wrote:

> Thanks Jay.. Dose it mean if one of scheduler/frame need a lot resource
> and keep ask for more resources from mesos, then it will cause other
> framework/scheduler hard to get resources? Any way I can configure the
> mesos to setup a resource consuming boundary for each framework?
>
> Best Regards
>
>
> *Jun Feng Liu*
> IBM China Systems & Technology Laboratory in Beijing
>
>   --
>  *Phone: *86-10-82452683
> * E-mail:* *liuj...@cn.ibm.com* 
> [image: IBM]
>
> BLD 28,ZGC Software Park
> No.8 Rd.Dong Bei Wang West, Dist.Haidian Beijing 100193
> China
>
>
>
>
>
>  *Jay Buffington >*
> Sent by: jaybuffing...@gmail.com
>
> 2014/08/18 02:44
>  Please respond to
> user@mesos.apache.org
>
>   To
> user@mesos.apache.org,
> cc
>   Subject
> Re: mesos scheduling
>
>
>
>
> On Sun, Aug 17, 2014 at 6:13 AM, Jun Feng Liu <*liuj...@cn.ibm.com*
> > wrote:
> I am trying to better understand how mesos allocator works. In the offer
> resource model, will mesos send the same offer to multiple framework? Or it
> just send all resource to one framework then wait the response from the the
> framework then try the next one?
>
> Mesos sends an offer to one scheduler (a scheduler is part of a framework)
> at a time.  That scheduler will have the offer until it uses it, gives it
> back or mesos rescinds it.
>
> This strategy was referred to as "pessimistic" by Google's Omega paper [1]
> and has drawbacks.  In order to address these points a new type of offer,
> an Optimistic Offer, is being considered.  See
> *https://issues.apache.org/jira/browse/MESOS-1607*
> 
>
> Jay
>
> [1]
> *http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf*
> 
>
>

Re: mesos scheduling

[Adam Bordelon]

That's correct (for now). We're looking into features that would support
preemption of running tasks, but currently a user/admin would have to
manually kill long-running tasks to scale down an over-provisioned
framework. Marathon also has a nice API (web or REST) for scaling down the
number of instances of a long-running service.


On Mon, Aug 18, 2014 at 1:43 AM, Jun Feng Liu  wrote:

> Thanks, Adam.. Sounds like it is going to be pretty effective when all the
> framework running a short tasks, then mesos can balance the resource
> allocation based on the DRF among the framework quickly. If one framework
> is happening to run some long tasks and take too many resources, mesos have
> to wait until some resource being free up to assign to other framework. Is
> it correct?
>
> Best Regards
>
>
> *Jun Feng Liu*
> IBM China Systems & Technology Laboratory in Beijing
>
>   --
>  [image: 2D barcode - encoded with contact information]
> *Phone: *86-10-82452683
> * E-mail:* *liuj...@cn.ibm.com* 
> [image: IBM]
>
> BLD 28,ZGC Software Park
> No.8 Rd.Dong Bei Wang West, Dist.Haidian Beijing 100193
> China
>
>
>
>
>
>  *Adam Bordelon >*
>
> 2014/08/18 16:26
>  Please respond to
> user@mesos.apache.org
>
>   To
> "user@mesos.apache.org" ,
> cc
> Jay Buffington 
> Subject
> Re: mesos scheduling
>
>
>
>
> Mesos uses a fair-sharing algorithm[1] to ensure that each framework
> registered with Mesos is ensured its fair share of resources. If you want
> more control over the groupings and weights of different frameworks, check
> out the roles and weights parameters: mesos-master --roles="services,batch"
> and --weights="services=2,batch=1" as described at
> *http://mesosphere.io/docs/mesos/deep-dive/mesos-master/*
> <http://mesosphere.io/docs/mesos/deep-dive/mesos-master/>
>
> Mesos uses these algorithms and parameters to decide which framework gets
> the next offer, so it won't affect already running tasks if one framework
> is already hogging the cluster when you start a new framework. But if you
> start killing tasks from the over-provisioned framework, those resources
> will be offered to the new framework(s) until it reaches its fair share.
>
> [1] *http://static.usenix.org/event/nsdi11/tech/full_papers/Ghodsi.pdf*
> <http://static.usenix.org/event/nsdi11/tech/full_papers/Ghodsi.pdf>
>
>
> On Sun, Aug 17, 2014 at 7:06 PM, Jun Feng Liu <*liuj...@cn.ibm.com*
> > wrote:
> Thanks Jay.. Dose it mean if one of scheduler/frame need a lot resource
> and keep ask for more resources from mesos, then it will cause other
> framework/scheduler hard to get resources? Any way I can configure the
> mesos to setup a resource consuming boundary for each framework?
> Best Regards
>
>
> * Jun Feng Liu*
> IBM China Systems & Technology Laboratory in Beijing
>
>   --
>  *Phone: *86-10-82452683
> * E-mail:* *liuj...@cn.ibm.com* 
> [image: IBM]
>
> BLD 28,ZGC Software Park
> No.8 Rd.Dong Bei Wang West, Dist.Haidian Beijing 100193
> China
>
>
>
>
>   *Jay Buffington <**m...@jaybuff.com* *>*
> Sent by: *jaybuffing...@gmail.com* 
>
> 2014/08/18 02:44
>
>
>   Please respond to
> *user@mesos.apache.org* 
>
>   To
> *user@mesos.apache.org* ,
> cc
>   Subject
> Re: mesos scheduling
>
>
>
>
>
>
> On Sun, Aug 17, 2014 at 6:13 AM, Jun Feng Liu <*liuj...@cn.ibm.com*
> > wrote:
> I am trying to better understand how mesos allocator works. In the offer
> resource model, will mesos send the same offer to multiple framework? Or it
> just send all resource to one framework then wait the response from the the
> framework then try the next one?
>
> Mesos sends an offer to one scheduler (a scheduler is part of a framework)
> at a time.  That scheduler will have the offer until it uses it, gives it
> back or mesos rescinds it.
>
> This strategy was referred to as "pessimistic" by Google's Omega paper [1]
> and has drawbacks.  In order to address these points a new type of offer,
> an Optimistic Offer, is being considered.  See
> *https://issues.apache.org/jira/browse/MESOS-1607*
> <https://issues.apache.org/jira/browse/MESOS-1607>
>
> Jay
>
> [1]
> *http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf*
> <http://eurosys2013.tudos.org/wp-content/uploads/2013/paper/Schwarzkopf.pdf>
>
>

Re: Alternate HDFS Filesystems + Hadoop on Mesos

[Adam Bordelon]

Okay, I guess MapRFS is protocol compatible with HDFS, but not
uri-compatible. I know the MapR guys have gotten MapR on Mesos working.
They may have more answers for you on how they accomplished this.

> why hard code the file prefixes?
We allow any uri, so we need to have handlers coded for each type of
protocol group, which so far includes hdfs/hftp/s3/s3n which use
hdfs::copyToLocal, or http/https/ftp/ftps which use net::download, or
file:// or an absolute/relative path for files pre-populated on the machine
(uses 'cp'). MapRFS (and Tachyon) would probably fit into the
hdfs::copyToLocal group so easily that it would be a one-line fix each.

> I really think the hdfs vs other prefixes should be looked at
I agree. Could you file a JIRA with your request? It should be an easy
enough change for us to pick up. I would also like to see Tachyon as a
possible filesystem for the fetcher.


On Fri, Aug 15, 2014 at 5:16 PM, John Omernik  wrote:

> I tried hdfs:/// and hdfs://cldbnode:7222/ Neither worked (examples below)
> I really think the hdfs vs other prefixes should be looked at. Like I said
> above, the tachyon project just added a env variable to address this.
>
>
>
> hdfs://cldbnode:7222/
>
> WARNING: Logging before InitGoogleLogging() is written to STDERR
> I0815 19:14:17.101666 22022 fetcher.cpp:76] Fetching URI 
> 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz'
> I0815 19:14:17.101780 22022 fetcher.cpp:105] Downloading resource from 
> 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz' to 
> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0003/executors/executor_Task_Tracker_5/runs/b3174e72-75ea-48be-bbb8-a9a6cc605018/hadoop-0.20.2-mapr-4.0.0.tgz'
> E0815 19:14:17.778833 22022 fetcher.cpp:109] HDFS copyToLocal failed: hadoop 
> fs -copyToLocal 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz' 
> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0003/executors/executor_Task_Tracker_5/runs/b3174e72-75ea-48be-bbb8-a9a6cc605018/hadoop-0.20.2-mapr-4.0.0.tgz'
> WARNING: org.apache.hadoop.metrics.jvm.EventCounter is deprecated. Please use 
> org.apache.hadoop.log.metrics.EventCounter in all the log4j.properties files.
> -copyToLocal: Wrong FS: 
> maprfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz, expected: 
> hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz
> Usage: hadoop fs [generic options] -copyToLocal [-p] [-ignoreCrc] [-crc] 
>  ... 
> Failed to fetch: hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz
> Failed to synchronize with slave (it's probably exited)
>
>
>
>
> hdfs:///
>
>
>
>
> I0815 19:10:45.006803 21508 fetcher.cpp:76] Fetching URI 
> 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz'
> I0815 19:10:45.007099 21508 fetcher.cpp:105] Downloading resource from 
> 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz' to 
> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0002/executors/executor_Task_Tracker_2/runs/22689054-aff6-4f7c-9746-a068a11ff000/hadoop-0.20.2-mapr-4.0.0.tgz'
> E0815 19:10:45.681922 21508 fetcher.cpp:109] HDFS copyToLocal failed: hadoop 
> fs -copyToLocal 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz' 
> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0002/executors/executor_Task_Tracker_2/runs/22689054-aff6-4f7c-9746-a068a11ff000/hadoop-0.20.2-mapr-4.0.0.tgz'
> WARNING: org.apache.hadoop.metrics.jvm.EventCounter is deprecated. Please use 
> org.apache.hadoop.log.metrics.EventCounter in all the log4j.properties files.
> -copyToLocal: Wrong FS: maprfs:/mesos/hadoop-0.20.2-mapr-4.0.0.tgz, expected: 
> hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz
> Usage: hadoop fs [generic options] -copyToLocal [-p] [-ignoreCrc] [-crc] 
>  ... 
> Failed to fetch: hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz
> Failed to synchronize with slave (it's probably exited)
>
>
>
> On Fri, Aug 15, 2014 at 5:38 PM, John Omernik  wrote:
>
>> I am away from my cluster right now, I trued doing a hadoop fs -ls
>> maprfs:// and that worked.   When I tries hadoop fs -ls hdfs:/// it failed
>> with wrong fs type.  With that error I didn't try it in the mapred-site.  I
>> will try it.  Still...why hard code the file prefixes? I guess I am curious
>> on how glusterfs would work, or others as they pop up.
>>  On Aug 15, 2014 5:04 PM, "Adam Bordelon"  wrote:
>>
>>> Can't you just use the hdfs:// protocol for maprfs? That should work
>>> just fine.
>>>
>>>
>

Re: MesosCon attendee introduction thread

[Adam Bordelon]

Hello friends,

I'm Adam from Mesosphere (adam-mesos), also an Apache Mesos committer, and
lately I've been working on a Kubernetes-Mesos framework with Niklas and
Connor. I'm excited to meet the rest of the community and discuss how we
can make the Mesos ecosystem even more awesome and get the whole world
using Mesos. Along with Connor, I will be leading the Mesos Frameworks SDK
workshop and providing tips on building and running frameworks on top of
Mesos. I'll be sticking around for the hackathon and staying in Chicago
through the weekend, so don't hesitate to invite me out to drinks and a
game of pool. There's gotta be a good dive bar around Chicago somewhere. :)

-Adam-
mesosphere.io


On Fri, Aug 15, 2014 at 11:14 PM, mohit soni 
wrote:

> I'm Mohit Soni. I work for eBay. I have been hacking things around
> Mesos for a while now.
>
> I am excited to talk about, running YARN alongside Mesos, alongwith
> Renan DelValle.
>
> Looking forward to meet everyone at MesosCon!
>
> -Mohit
> @mohitsoni
>
> On Thu, Aug 14, 2014 at 9:06 AM, Dave Lester  wrote:
> >
> > Hi All,
> >
> > I thought it would be nice to kickoff a thread for folks to introduce
> > themselves in advance of #MesosCon
> > , so here goes:
> >
> > My name is Dave Lester, and I am Open Source Advocate at Twitter. Twitter
> > is an organizing sponsor for #MesosCon, and I've worked closely with
> Chris
> > Aniszczyk, the Linux Foundation, and a great team of volunteers to
> > hopefully make this an awesome community event.
> >
> > I'm interested in meeting more companies using Mesos that we can add
> > to our #PoweredByMesos
> > list ,
> and
> > chatting with folks about Apache Aurora <
> http://aurora.incubator.apache.org>.
> > Right now my Thursday and Friday evenings are free, so let's grab a beer
> > and chat more.
> >
> > I'm also on Twitter: @davelester
> >
> > Next!
> >
> >
>

Re: Alternate HDFS Filesystems + Hadoop on Mesos

[Adam Bordelon]

Thanks a lot John, the JIRA looks great! We'll get on it soon.

Tim, I'd be happy to shepherd this change for you.
Also, we spoke with H.Y. from Tachyon at Mesosphere recently, and we (I and
probably others) would be glad to help with the Tachyon Framework as well.
Should be much easier than handling persistent storage like HDFS.


On Mon, Aug 18, 2014 at 8:08 AM, Tim St Clair  wrote:

> inline
>
> --
>
> *From: *"Adam Bordelon" 
> *To: *user@mesos.apache.org
> *Sent: *Monday, August 18, 2014 4:43:34 AM
> *Subject: *Re: Alternate HDFS Filesystems + Hadoop on Mesos
>
>
> Okay, I guess MapRFS is protocol compatible with HDFS, but not
> uri-compatible. I know the MapR guys have gotten MapR on Mesos working.
> They may have more answers for you on how they accomplished this.
>
> > why hard code the file prefixes?
> We allow any uri, so we need to have handlers coded for each type of
> protocol group, which so far includes hdfs/hftp/s3/s3n which use
> hdfs::copyToLocal, or http/https/ftp/ftps which use net::download, or
> file:// or an absolute/relative path for files pre-populated on the machine
> (uses 'cp'). MapRFS (and Tachyon) would probably fit into the
> hdfs::copyToLocal group so easily that it would be a one-line fix each.
>
> > I really think the hdfs vs other prefixes should be looked at
> I agree. Could you file a JIRA with your request? It should be an easy
> enough change for us to pick up. I would also like to see Tachyon as a
> possible filesystem for the fetcher.
>
> +1 & I'll take.  IMHO we should check support for *HCFS, which should be a
> pretty straight forward check.
>
> Also, fwiw I'm interested in rallying folks on a Tachyon Framework in the
> not-too-distant future, for anyone who is interested.  Probably follow the
> spark model and try to push upstream.
>
>
>
> On Fri, Aug 15, 2014 at 5:16 PM, John Omernik  wrote:
>
>> I tried hdfs:/// and hdfs://cldbnode:7222/ Neither worked (examples
>> below) I really think the hdfs vs other prefixes should be looked at. Like
>> I said above, the tachyon project just added a env variable to address
>> this.
>>
>>
>>
>> hdfs://cldbnode:7222/
>>
>> WARNING: Logging before InitGoogleLogging() is written to STDERR
>> I0815 19:14:17.101666 22022 fetcher.cpp:76] Fetching URI 
>> 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz'
>> I0815 19:14:17.101780 22022 fetcher.cpp:105] Downloading resource from 
>> 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz' to 
>> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0003/executors/executor_Task_Tracker_5/runs/b3174e72-75ea-48be-bbb8-a9a6cc605018/hadoop-0.20.2-mapr-4.0.0.tgz'
>> E0815 19:14:17.778833 22022 fetcher.cpp:109] HDFS copyToLocal failed: hadoop 
>> fs -copyToLocal 'hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz' 
>> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0003/executors/executor_Task_Tracker_5/runs/b3174e72-75ea-48be-bbb8-a9a6cc605018/hadoop-0.20.2-mapr-4.0.0.tgz'
>> WARNING: org.apache.hadoop.metrics.jvm.EventCounter is deprecated. Please 
>> use org.apache.hadoop.log.metrics.EventCounter in all the log4j.properties 
>> files.
>> -copyToLocal: Wrong FS: 
>> maprfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz, expected: 
>> hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz
>> Usage: hadoop fs [generic options] -copyToLocal [-p] [-ignoreCrc] [-crc] 
>>  ... 
>> Failed to fetch: hdfs://hadoopmapr1:7222/mesos/hadoop-0.20.2-mapr-4.0.0.tgz
>> Failed to synchronize with slave (it's probably exited)
>>
>>
>>
>>
>> hdfs:///
>>
>>
>>
>>
>> I0815 19:10:45.006803 21508 fetcher.cpp:76] Fetching URI 
>> 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz'
>> I0815 19:10:45.007099 21508 fetcher.cpp:105] Downloading resource from 
>> 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz' to 
>> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0002/executors/executor_Task_Tracker_2/runs/22689054-aff6-4f7c-9746-a068a11ff000/hadoop-0.20.2-mapr-4.0.0.tgz'
>> E0815 19:10:45.681922 21508 fetcher.cpp:109] HDFS copyToLocal failed: hadoop 
>> fs -copyToLocal 'hdfs:///mesos/hadoop-0.20.2-mapr-4.0.0.tgz' 
>> '/tmp/mesos/slaves/20140815-103603-1677764800-5050-24315-2/frameworks/20140815-154511-1677764800-5050-7162-0002/executors/executor_Task_Tracker_2/runs/226890

Re: Data Center Awareness - Mesos

[Adam Bordelon]

You could use mesos-slave --attributes="datacenter:us_east" or whatever,
and those attributes will show up in your resource offers, so you can use
them to decide which tasks to launch in what datacenter. For now, it's
probably recommended that you keep your masters in the same datacenter, for
replicated-log sync latency.


On Thu, Aug 21, 2014 at 6:45 AM, John Omernik  wrote:

> I was wondering... does Mesos have any concept of datacenter awareness?
> I.e. if you have two primary data centers, nodes can be flagged as such,
> and then certain frameworks can be localized to a datacenter, or, if the
> frameworks allow, be distributed across high latency links?  Or is this all
> just crazy talk? :)
>
>
>

Re: Mesos make check failed

[Adam Bordelon]

That's correct behavior. We have some tests that are a little flaky, so we
disable them to prevent spurious test failures.
Glad to see make check is passing for you now. What's next?

On Thu, Sep 11, 2014 at 4:15 PM, Luyi Wang  wrote:

> updated, after rebuild the source and rerun the make check.
>
> 404 test ran and passed. 6 tests are disabled for unknown reason.
>
>
> [--] Global test environment tear-down
> [==] 404 tests from 66 test cases ran. (275125 ms total)
> [  PASSED  ] 404 tests.
>
>   YOU HAVE 6 DISABLED TESTS
>
>
> On Wed, Sep 10, 2014 at 3:00 PM, Luyi Wang  wrote:
>
>> Thanks. I did run everything under 'build' folder.  I just removed all
>> built result by using "make clean" in regarding the random failure and
>> rebuilding now.  Will probably update the thread later, probably tomorrow.
>>
>> Thanks.
>>
>> On Wed, Sep 10, 2014 at 2:56 PM, Till Toenshoff  wrote:
>>
>>> Luyi,
>>>
>>> please check the link that I had provided to enable enhanced verbosity
>>> logging when running the tests.
>>> Note that you do not need to rerun "make check” if you did that already
>>> (which you obviously did).
>>>
>>> For your convenience, I copy pasted the answer and adapted it to fit one
>>> of your failed tests (MasterAuthorizationTest.AuthorizedTask). You may
>>> repeat the steps below for all other failed tests
>>> (e.g. ShutdownTest.ShutdownEndpointBadCredentials as per your provided log
>>> file).
>>>
>>> The following assumes that your current directory (pwd) is the build folder
>>> within the extracted / cloned Mesos project directory structure.
>>>
>>> Let's assume that a test named MasterAuthorizationTest.AuthorizedTask had
>>> failed for you. Now go ahead and run that test individually, with enhanced
>>> output:
>>>
>>> ./bin/mesos-tests.sh
>>> --gtest_filter="MasterAuthorizationTest.AuthorizedTask" --verbose
>>>
>>> That should reveal some more insights of the failure reasoning.
>>>
>>> In cases where the above still has too little output to understand the
>>> problem, for some rare cases, it could be beneficial to increase the
>>> verbosity even further.
>>>
>>> GLOG_v=2 ./bin/mesos-tests.sh
>>> --gtest_filter="MasterAuthorizationTest.AuthorizedTask" --verbose
>>>
>>> That will enable all common VLOG levels of mesos. Those however usually
>>> are not meant for users but for developers. So don't expect their output to
>>> be too user friendly.
>>> Hope that helps,
>>> Till
>>>
>>>
>>> On Sep 10, 2014, at 11:40 PM, Luyi Wang  wrote:
>>>
>>> seems it is more on random.
>>>
>>> I am using the source code checked out from git. The latest commit is
>>>
>>> commit fd798ffbeecee644b4674a9149c38d563bfa044e
>>> Author: Timothy St. Clair 
>>> Date:   Tue Sep 9 13:28:10 2014 -0500
>>>
>>> Update deploy_dir from localstate to sysconf
>>>
>>> Updates the mesos-env files to install to /etc/mesos vs.
>>> /var/lib/deploy/mesos.
>>>
>>> Review: https://reviews.apache.org/r/25447
>>>
>>>
>>> The make check take less time than the first time running. The failed
>>> test were also different.
>>>
>>> More insight would be helpful.
>>>
>>> Thanks.
>>>
>>>
>>> On Wed, Sep 10, 2014 at 1:58 PM, Luyi Wang 
>>> wrote:
>>>
 rerunning the make check again with output redirect to a log file.  It
 would take a while. will update afterward.

 On Wed, Sep 10, 2014 at 1:46 PM, Till Toenshoff 
 wrote:

>
> What's the error message / logs associated for those failed tests?
>
>
> To expand on what Tim said, see the following for details:
>
> http://stackoverflow.com/questions/22619124/when-running-make-check-on-mesos-one-of-the-tests-fails-what-now
>
>
>
> Tim
>
> On Wed, Sep 10, 2014 at 1:27 PM, Luyi Wang 
> wrote:
>
>> [  FAILED  ] 3 tests, listed below:
>> [  FAILED  ] DRFAllocatorTest.DRFAllocatorProcess
>> [  FAILED  ] ResourceOffersTest.TaskUsesNoResources
>> [  FAILED  ] ShutdownTest.ShutdownEndpointGoodACLs
>>
>>
>>
>
>

>>> 
>>>
>>>
>>>
>>
>

[VOTE] Release Apache Mesos 0.20.1 (rc2)

[Adam Bordelon]

Hi all,

Please vote on releasing the following candidate as Apache Mesos 0.20.1.


0.20.1 includes the following:

Minor bug fixes for docker integration, network isolation, etc.

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=0.20.1-rc2


The candidate for Mesos 0.20.1 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz

The tag to be voted on is 0.20.1-rc2:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.20.1-rc2

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1034

Please vote on releasing this package as Apache Mesos 0.20.1!

The vote is open until  and passes if a majority of at least 3 +1 PMC votes
are cast.

[ ] +1 Release this package as Apache Mesos 0.20.1
[ ] -1 Do not release this package because ...

Thanks,
-Adam-

Re: [VOTE] Release Apache Mesos 0.20.1 (rc2)

[Adam Bordelon]

Update: The vote is open until Mon Sep 22 10:00:00 PDT 2014 and passes if a
majority of at least 3 +1 PMC votes are cast.

On Wed, Sep 17, 2014 at 6:27 PM, Adam Bordelon  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.20.1.
>
>
> 0.20.1 includes the following:
>
> 
> Minor bug fixes for docker integration, network isolation, etc.
>
> 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=0.20.1-rc2
>
> 
>
> The candidate for Mesos 0.20.1 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz
>
> The tag to be voted on is 0.20.1-rc2:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.20.1-rc2
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1034
>
> Please vote on releasing this package as Apache Mesos 0.20.1!
>
> The vote is open until  and passes if a majority of at least 3 +1 PMC
> votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.20.1
> [ ] -1 Do not release this package because ...
>
> Thanks,
> -Adam-
>

Re: [VOTE] Release Apache Mesos 0.20.1 (rc2)

[Adam Bordelon]

Great. I'll roll that into an rc3 today. Any other patch requests for rc3?

On Thu, Sep 18, 2014 at 2:36 AM, Benjamin Hindman <
benjamin.hind...@gmail.com> wrote:

> I've committed Tim's fix, we can cut another release candidate and restart
> the vote.
>
> On Wed, Sep 17, 2014 at 11:07 PM, Tim Chen  wrote:
>
> > -1
> >
> > The docker test failed when I removed the image, and found a problem from
> > the docker pull implementation.
> > I've created a reviewboard for a fix: https://reviews.apache.org/r/25758
> >
> > Will like to get this fixed before releasing it.
> >
> > Tim
> >
> > On Wed, Sep 17, 2014 at 9:10 PM, Vinod Kone  wrote:
> >
> >> +1 (binding)
> >>
> >> make check passes on CentOS 5.5 w/ gcc 4.8.2.
> >>
> >>
> >>
> >> On Wed, Sep 17, 2014 at 7:42 PM, Adam Bordelon 
> >> wrote:
> >>
> >>> Update: The vote is open until Mon Sep 22 10:00:00 PDT 2014 and passes
> >>> if a majority of at least 3 +1 PMC votes are cast.
> >>>
> >>> On Wed, Sep 17, 2014 at 6:27 PM, Adam Bordelon 
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Please vote on releasing the following candidate as Apache Mesos
> 0.20.1.
> >>>>
> >>>>
> >>>> 0.20.1 includes the following:
> >>>>
> >>>>
> 
> >>>> Minor bug fixes for docker integration, network isolation, etc.
> >>>>
> >>>> 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=0.20.1-rc2
> >>>>
> >>>>
> 
> >>>>
> >>>> The candidate for Mesos 0.20.1 release is available at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz
> >>>>
> >>>> The tag to be voted on is 0.20.1-rc2:
> >>>>
> >>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.20.1-rc2
> >>>>
> >>>> The MD5 checksum of the tarball can be found at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.md5
> >>>>
> >>>> The signature of the tarball can be found at:
> >>>>
> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.asc
> >>>>
> >>>> The PGP key used to sign the release is here:
> >>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>>>
> >>>> The JAR is up in Maven in a staging repository here:
> >>>>
> https://repository.apache.org/content/repositories/orgapachemesos-1034
> >>>>
> >>>> Please vote on releasing this package as Apache Mesos 0.20.1!
> >>>>
> >>>> The vote is open until  and passes if a majority of at least 3 +1 PMC
> >>>> votes are cast.
> >>>>
> >>>> [ ] +1 Release this package as Apache Mesos 0.20.1
> >>>> [ ] -1 Do not release this package because ...
> >>>>
> >>>> Thanks,
> >>>> -Adam-
> >>>>
> >>>
> >>>
> >>
> >
>

Re: [VOTE] Release Apache Mesos 0.20.1 (rc2)

[Adam Bordelon]

I doubt MESOS-1195 will make it into 0.20.1, because
a) There isn't a ShipIt on the patch yet. Jie and Tim are still iterating
b) As Vinod mentioned, "we should not rush this into 0.20.1 because this is
not a bug in 0.20.0". Mesos 0.21 should be out in a few weeks, and will
include this patch.

On Thu, Sep 18, 2014 at 11:18 AM, Dick Davies 
wrote:

> Don't suppose there's any chance of a fix for
>
> https://issues.apache.org/jira/browse/MESOS-1195
>
> is there?
>
> (I'll settle for a workaround to get mesos running on EL7 somehow, mind)
>
>
> On 18 September 2014 18:18, Adam Bordelon  wrote:
> > Great. I'll roll that into an rc3 today. Any other patch requests for
> rc3?
> >
> > On Thu, Sep 18, 2014 at 2:36 AM, Benjamin Hindman
> >  wrote:
> >>
> >> I've committed Tim's fix, we can cut another release candidate and
> restart
> >> the vote.
> >>
> >> On Wed, Sep 17, 2014 at 11:07 PM, Tim Chen  wrote:
> >>
> >> > -1
> >> >
> >> > The docker test failed when I removed the image, and found a problem
> >> > from
> >> > the docker pull implementation.
> >> > I've created a reviewboard for a fix:
> https://reviews.apache.org/r/25758
> >> >
> >> > Will like to get this fixed before releasing it.
> >> >
> >> > Tim
> >> >
> >> > On Wed, Sep 17, 2014 at 9:10 PM, Vinod Kone 
> wrote:
> >> >
> >> >> +1 (binding)
> >> >>
> >> >> make check passes on CentOS 5.5 w/ gcc 4.8.2.
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 17, 2014 at 7:42 PM, Adam Bordelon 
> >> >> wrote:
> >> >>
> >> >>> Update: The vote is open until Mon Sep 22 10:00:00 PDT 2014 and
> passes
> >> >>> if a majority of at least 3 +1 PMC votes are cast.
> >> >>>
> >> >>> On Wed, Sep 17, 2014 at 6:27 PM, Adam Bordelon 
> >> >>> wrote:
> >> >>>
> >> >>>> Hi all,
> >> >>>>
> >> >>>> Please vote on releasing the following candidate as Apache Mesos
> >> >>>> 0.20.1.
> >> >>>>
> >> >>>>
> >> >>>> 0.20.1 includes the following:
> >> >>>>
> >> >>>>
> >> >>>>
> 
> >> >>>> Minor bug fixes for docker integration, network isolation, etc.
> >> >>>>
> >> >>>> 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=0.20.1-rc2
> >> >>>>
> >> >>>>
> >> >>>>
> 
> >> >>>>
> >> >>>> The candidate for Mesos 0.20.1 release is available at:
> >> >>>>
> >> >>>>
> >> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz
> >> >>>>
> >> >>>> The tag to be voted on is 0.20.1-rc2:
> >> >>>>
> >> >>>>
> >> >>>>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.20.1-rc2
> >> >>>>
> >> >>>> The MD5 checksum of the tarball can be found at:
> >> >>>>
> >> >>>>
> >> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.md5
> >> >>>>
> >> >>>> The signature of the tarball can be found at:
> >> >>>>
> >> >>>>
> >> >>>>
> https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc2/mesos-0.20.1.tar.gz.asc
> >> >>>>
> >> >>>> The PGP key used to sign the release is here:
> >> >>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
> >> >>>>
> >> >>>> The JAR is up in Maven in a staging repository here:
> >> >>>>
> >> >>>>
> https://repository.apache.org/content/repositories/orgapachemesos-1034
> >> >>>>
> >> >>>> Please vote on releasing this package as Apache Mesos 0.20.1!
> >> >>>>
> >> >>>> The vote is open until  and passes if a majority of at least 3 +1
> PMC
> >> >>>> votes are cast.
> >> >>>>
> >> >>>> [ ] +1 Release this package as Apache Mesos 0.20.1
> >> >>>> [ ] -1 Do not release this package because ...
> >> >>>>
> >> >>>> Thanks,
> >> >>>> -Adam-
> >> >>>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >
> >
>

[VOTE] Release Apache Mesos 0.20.1 (rc3)

[Adam Bordelon]

Hi all,

Please vote on releasing the following candidate as Apache Mesos 0.20.1.


0.20.1 includes the following:

Minor bug fixes for docker integration, network isolation, build, etc.

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=0.20.1-rc3


The candidate for Mesos 0.20.1 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc3/mesos-0.20.1.tar.gz

The tag to be voted on is 0.20.1-rc3:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.20.1-rc3

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc3/mesos-0.20.1.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.20.1-rc3/mesos-0.20.1.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1036

Please vote on releasing this package as Apache Mesos 0.20.1!

The vote is open until Mon Sep 22 17:00:00 PDT 2014 and passes if a
majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.20.1
[ ] -1 Do not release this package because ...

Thanks,
Adam and Bhuvan

[RESULT][VOTE] Release Apache Mesos 0.20.1 (rc3)

[Adam Bordelon]

Hi all,

The vote for Mesos 0.20.1 (rc3) has passed with the following votes.

+1 (Binding)
--
*** Vinod Kone
*** Till Toenshoff
*** Niklas Nielsen
*** Jie Yu

+1 (Non-binding)
--
*** Tim Chen
*** Tom Arnfeld

There were no 0 or -1 votes.

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

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=0.20.1

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

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

Thanks,
-Adam-