Re: [VOTE] Release Apache Mesos 1.9.0 (rc3)

[Gilbert Song]

+1 (binding).

Tested on our internal CI. Green on most of the platforms:
Configuration Matrix Plain SSL CMake Clang BUILD_ISOLATORS
mac
[image: Not run]
[image: Success]

[image: Not run]
[image: Not run]
[image: Not run]
mesos-ec2-centos-6
[image: Not run]
[image: Unstable]

[image: Not run]
[image: Not run]
[image: Not run]
mesos-ec2-centos-7
[image: Success]

[image: Success]

[image: Success]

[image: Not run]
[image: Not run]
mesos-ec2-debian-8
[image: Not run]
[image: Unstable]

[image: Not run]
[image: Not run]
[image: Not run]
mesos-ec2-debian-9
[image: Not run]
[image: Success]

[image: Not run]
[image: Not run]
[image: Not run]
mesos-ec2-ubuntu-14.04
[image: Not run]
[image: Success]

[image: Not run]
[image: Not run]
[image: Not run]
mesos-ec2-ubuntu-16.04
[image: Success]

[image: Success]

[image: Success]

[image: Success]

[image: Success]


The only two failed tests are known flakiness.

   - mesos-ec2-centos-6-SSL.Mesos.ExecutorAuthorizationTest.FailedSubscribe
   - mesos-ec2-debian-8-SSL.MESOS_TESTS_ABORTED.xml.[empty]

-Gilbert

On Tue, Sep 3, 2019 at 10:43 AM Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI.
>
> *Revision*: 5e79a584e6ec3e9e2f96e8bf418411df9dafac2e
>
>- refs/tags/1.9.0-rc3
>
> Configuration Matrix gcc clang
> centos:7 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:16.04 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Success]
> 

Re: Provisioning containers with configuration file via sandbox mount or copy via entrypoint.sh

[Gilbert Song]

It depends on how do you want to manage the configuration files for your
containers - dynamic or static.

   - Dynamic
  - Fetch via URI - you probably do not need your application
  entrypoint to fetch. Instead Mesos and marathon supports fetching URIs to
  your container sandbox.
  http://mesos.apache.org/documentation/latest/fetcher/
  - Pass into the container as a file based secret if it is sensitive.

  http://mesos.apache.org/documentation/latest/secrets/#file-based-secrets
  - Environment Variable.
   - Static
  - Host_path volume - mounting a host path or file into your container.

  
http://mesos.apache.org/documentation/latest/container-volume/#host_path-volume-source
  - Build it in your container image if those configurations are not
  expected to be changed.

> Furthermore this page[1] says the sandbox is considered read only, yet
the stdout and stderr are located there???
I think the document
 means
that sandbox is not expected to be touched by any 3rd party software or
people *other than* Mesos, executor and task/application.

-Gilbert

On Sun, Jul 21, 2019 at 3:22 AM Marc Roos  wrote:

>
>
> What would be the adviced way to add a configuration file to a container
> being used at startup. I am now fetching the files and then create an
> entrypoint.sh that copies this from the sandbox.
>
> Creating these custom entrypoints.sh is cumbersome. I thought about
> mounting the path's of the sandbox in the container but don't have good
> example to get this working[0]. Furthermore this page[1] says the
> sandbox is considered read only, yet the stdout and stderr are located
> there???
>
> Is there a (security) advantage copying files from the sandbox at
> startup or just use a mount point?
>
> [0]
> https://www.mail-archive.com/user@mesos.apache.org/msg10445.html
>
> [1]
> http://mesos.apache.org/documentation/latest/sandbox/
>

Re: Is chained cni networks supported in mesos 1.7

[Gilbert Song]

Are you interested in implementing the CNI chain support?

-Gilbert

On Wed, Jul 24, 2019 at 12:52 PM Marc Roos  wrote:

>
> Hmm, I guess I should not get my hopes up this will be there soon?
> [0]
> https://issues.apache.org/jira/browse/MESOS-7178
>
>
>
> -Original Message-
> From: Jie Yu [mailto:yujie@gmail.com]
> Sent: woensdag 24 juli 2019 21:35
> To: user
> Subject: Re: Is chained cni networks supported in mesos 1.7
>
> No, not yet
>
> On Wed, Jul 24, 2019 at 12:27 PM Marc Roos 
> wrote:
>
>
>
>
>
>
>
> This error message of course
> E0724 21:19:17.852210  1160 cni.cpp:330] Failed to parse CNI
> network
> configuration file '/etc/mesos-cni/93-chain.conflist': Protobuf
> parse
> failed: Missing required fields: typ
>
>
> -Original Message-
> Subject: Is chained cni networks supported in mesos 1.7
>
>
> I am getting this error, while I don not have problems using it
> with
> cnitool.
>
>  cni.cpp:330] Failed to parse CNI network configuration file
> '/etc/mesos-cni/93-chain-routing-overwrite.conflist.bak': Protobuf
> parse
> failed: Missing required fields: type
>
> [@ mesos-cni]# cat 93-chain.conflist
> {
>   "name": "test-chain",
>   "plugins": [{
> "type": "bridge",
> "bridge": "test-chain0",
> "isGateway": false,
> "isDefaultGateway": false,
> "ipMasq": false,
> "ipam": {
> "type": "host-local",
> "subnet": "10.15.15.0/24"
> }
> },
> {
>   "type": "portmap",
>   "capabilities": {"portMappings": true},
>   "snat": false
> }]
> }
>
>
> [@ mesos-cni]#  CNI_PATH="/usr/libexec/cni/"
> NETCONFPATH="/etc/mesos-cni" cnitool-0.5.2 add test-chain
> /var/run/netns/testing {
> "ip4": {
> "ip": "10.15.15.2/24",
> "gateway": "10.15.15.1"
> },
> "dns": {}
>
>
>
>
>
>

Re: [mesos-mail] Cant get sandbox_path to work

[Gilbert Song]

Are you using Marathon?

The Mesos SANDBOX_PATH volume was supported by Marathon as the pod's
ephemeral volume. Please note that Mesos framework API is different from
Marathon API and refer to Marathon documentation if necessary.

-Gilbert

On Sat, Jul 20, 2019 at 5:25 PM Marc Roos  wrote:

>
> Don't know how to apply this manual correctly to map a image folder to
> the sandbox.
>
> http://mesos.apache.org/documentation/latest/container-volume/#sandbox_path-volume-source
>
> {
>   "id": "/test2",
>   "user": "nobody",
>   "cpus": 1,
>   "mem": 256,
>   "disk": 0,
>   "instances": 1,
>   "acceptedResourceRoles": ["*"],
>   "backoffSeconds": 10,
>   "networks": [
> { "mode": "container", "name": "cni" }
>   ],
>   "container": {
> "type": "MESOS",
> "docker": {
> "image": "test",
> "credential": null,
> "forcePullImage": true
> },
> "volumes": [
>   {
>   "mode": "RW",
> "container_path": "/usr/local/tomcat/logs",
>   "source": {
>  "type": "SANDBOX_PATH",
>  "sandbox_path": {
>  "type": "SELF",
>  "path": "tmp"
>  }
>   }
>   }
>   ]
>   }
> }
>
>

Re: Subject: [VOTE] Release Apache Mesos 1.8.0 (rc1)

[Gilbert Song]

-1 for rc1.

I would like to have MESOS-9704
 (backported to 1.8.x
branch) in for 1.8.0, otherwise it could be a regression for some conner
cases.

-Gilbert

On Tue, Apr 16, 2019 at 8:40 AM Benno Evers  wrote:

> You're right, I forgot to make a 'CLI' subheading when I added the
> CLI-related highlights. I added that now that on both branches.
>
> The other items seem to be mostly editorial changes, as far as I can tell.
> If you feel anything in particular is missing, maybe you could just send me
> a list and we can make sure to have it included in the release blogpost and
> the master CHANGELOG?
>
> On Mon, Apr 15, 2019 at 11:37 PM Benjamin Mahler 
> wrote:
>
>> The CHANGELOG highlights seem a bit lacking?
>>
>> - For some reason, the task CLI command is listed in a performance
>> section?
>> - The parallel endpoint serving changes are in the longer list of items,
>> seems like we highlight them in the performance section? Maybe we could be
>> specific too about what we did additionally vs 1.7.0, since we already
>> announced parallel state reads in 1.7.0?
>> - We also have some additional allocator related performance improvements
>> in 1.8.0 that we need to add.
>> - Do we want to say something w.r.t.
>> https://issues.apache.org/jira/browse/MESOS-9211?
>>
>> Not sure to what degree we care about an accurate CHANGELOG in the 1.8.0
>> tag vs updating the 1.8.0 CHANGELOG on master?
>>
>> On Mon, Apr 15, 2019 at 2:26 PM Benno Evers 
>> wrote:
>>
>> > Hi all,
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 1.8.0.
>> >
>> >
>> > 1.8.0 includes the following:
>> >
>> >
>> 
>> >  * Operation feedback for v1 schedulers.
>> >  * Per-framework minimum allocatable resources.
>> >  * New CLI subcommands `task attach` and `task exec`.
>> >  * New `linux/seccomp` isolator.
>> >  * Support for Docker v2 Schema2 manifest format.
>> >  * XFS quota for persistent volumes.
>> >  * **Experimental** Support for the new CSI v1 API.
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> >
>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.8.0-rc1
>> >
>> >
>> 
>> >
>> > The candidate for Mesos 1.8.0 release is available at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.8.0-rc1/mesos-1.8.0.tar.gz
>> >
>> > The tag to be voted on is 1.8.0-rc1:
>> > https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.8.0-rc1
>> >
>> > The SHA512 checksum of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.8.0-rc1/mesos-1.8.0.tar.gz.sha512
>> >
>> > The signature of the tarball can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/1.8.0-rc1/mesos-1.8.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 in a staging repository here:
>> > https://repository.apache.org/content/repositories/orgapachemesos-1251
>> >
>> > Please vote on releasing this package as Apache Mesos 1.8.0!
>> >
>> > The vote is open until Thursday, April 18 and passes if a majority of at
>> > least 3 +1 PMC votes are cast.
>> >
>> > [ ] +1 Release this package as Apache Mesos 1.8.0
>> > [ ] -1 Do not release this package because ...
>> >
>> > Thanks,
>> > Benno and Joseph
>> >
>>
>
>
> --
> Benno Evers
> Software Engineer, Mesosphere
>

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

[Gilbert Song]

 Hi all,

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

+1 (Binding)
--
Vinod Kone
Greg Mann
Gilbert Song
Chun-Hung Hsiao

+1 (Non-binding)
--
Meng Zhu

There were no 0 or -1 votes.

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

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://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.5.3

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

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

Thanks,
Gilbert

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

[Gilbert Song]

+1 (binding).

On Fri, Feb 22, 2019 at 9:43 AM Meng Zhu  wrote:

> +1, ran through out internal CI, only flaky failures
>
> On Thu, Feb 21, 2019 at 11:41 AM Greg Mann  wrote:
>
> > +1
> >
> > Built on CentOS 7.4 and ran all tests as root. Only 3 test failures were
> > observed, all known flakes.
> >
> > Cheers,
> > Greg
> >
> > On Wed, Feb 20, 2019 at 7:12 AM Vinod Kone  wrote:
> >
> >> +1
> >>
> >> Ran this on ASF CI.
> >>
> >> The red builds are a flaky infra issue and a known flaky test
> >> .
> >>
> >> *Revision*: 58cc918e9acc2865bb07047d3d2dff156d1708b2
> >>
> >>- refs/tags/1.7.2-rc1
> >>
> >> Configuration Matrix gcc clang
> >> centos:7 --verbose --disable-libtool-wrappers
> >> --disable-parallel-test-execution --enable-libevent --enable-ssl
> autotools
> >> [image: Failed]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%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-Release/66/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%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 --disable-libtool-wrappers --disable-parallel-test-execution
> >> autotools
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,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-Release/66/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> [image: Not run]
> >> ubuntu:16.04 --verbose --disable-libtool-wrappers
> >> --disable-parallel-test-execution --enable-libevent --enable-ssl
> autotools
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.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/66/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> >> autotools
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> [image: Success]
> >> <
> >>
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/66/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >> >
> >> cmake
> >> [image: Success]
> >> <
> 

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

[Gilbert Song]

+1 (binding).

On Thu, Feb 21, 2019 at 2:18 PM Gastón Kleiman  wrote:

> +1
>
> Ran it through Mesosphere's internal CI. Only 7 test failures were
> observed, all known flakes.
>
> On Fri, Feb 15, 2019 at 11:49 AM Vinod Kone  wrote:
>
>> +1 (binding)
>>
>> Tested on ASF CI. Red builds are known flaky tests or unrelated infra
>> issues.
>>
>>
>> *Revision*: 1fee9b5365bf2424e4768dc1d5209c6c78dfece6
>>
>>- refs/tags/1.4.3-rc2
>>
>> Configuration Matrix gcc clang
>> centos:7 --verbose --disable-libtool-wrappers
>> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
>> [image: Failed]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%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: Failed]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%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 --disable-libtool-wrappers --disable-parallel-test-execution
>> autotools
>> [image: Failed]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,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-Release/64/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> [image: Not run]
>> ubuntu:16.04 --verbose --disable-libtool-wrappers
>> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
>> [image: Success]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> [image: Success]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.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/64/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> [image: Success]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
>> autotools
>> [image: Failed]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> [image: Success]
>> <
>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/64/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.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/64/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--disable-libtool-wrappers%20--disable-parallel-test-execution,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A16.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
>> >
>> [image: Failed]
>> <
>> 

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

[Gilbert Song]

+1 (binding).

On Wed, Feb 20, 2019 at 5:42 PM Meng Zhu  wrote:

> +1 -- ran on centos 7.4 with only known flaky tests
>
> -Meng
>
> On Wed, Feb 20, 2019 at 4:57 PM Gastón Kleiman 
> wrote:
>
>> +1 (binding) — ran the build through Mesosphere's internal CI and only
>> two known flaky tests failed.
>>
>> On Tue, Feb 19, 2019 at 11:56 AM Greg Mann  wrote:
>>
>>> Hi all,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 1.6.2.
>>>
>>>
>>> 1.6.2 includes a number of bug fixes since 1.6.1; the CHANGELOG for the
>>> release is available at:
>>>
>>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.6.2-rc1
>>>
>>> 
>>>
>>> The candidate for Mesos 1.6.2 release is available at:
>>> https://dist.apache.org/repos/dist/dev/mesos/1.6.2-rc1/mesos-1.6.2.tar.gz
>>>
>>> The tag to be voted on is 1.6.2-rc1:
>>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.6.2-rc1
>>>
>>> The SHA512 checksum of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.6.2-rc1/mesos-1.6.2.tar.gz.sha512
>>>
>>> The signature of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/1.6.2-rc1/mesos-1.6.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 in a staging repository here:
>>> https://repository.apache.org/content/repositories/orgapachemesos-1246
>>>
>>> Please vote on releasing this package as Apache Mesos 1.6.2!
>>>
>>> The vote is open until Fri Feb 22 11:54 PST 2019, and passes if a
>>> majority of at least 3 +1 PMC votes are cast.
>>>
>>> [ ] +1 Release this package as Apache Mesos 1.6.2
>>> [ ] -1 Do not release this package because ...
>>>
>>> Thanks,
>>> Greg
>>>
>>

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

[Gilbert Song]

-1

Sorry, given the fact that this is very likely to be the last point release
for Mesos 1.4, there are some security improvement patches that are very
useful for users but not included in this RC. I would down vote it for
another cut, which could include more improvements from 1.4.x branch.

-Gilbert

On Tue, Jan 29, 2019 at 6:00 PM Vinod Kone  wrote:

> +1
>
> Tested in ASF CI. Red builds are known flakes.
>
> *Revision*: fcfe1904e45726ca96fc6707d8b227a16664f4f8
>
>- refs/tags/1.4.3-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Failed]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:16.04 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Failed]
> 
> [image: Success]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> [image: Failed]
> 
> [image: Failed]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 

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

[Gilbert Song]

 Hi all,

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

+1 (Binding)
--
Jie Yu
Vinod Kone
Chun-Hung Hsiao
Gilbert Song

There were no 0 or -1 votes.

Please find the release at:
https://dist.apache.org/repos/dist/release/mesos/1.5.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://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.5.2

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

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

Thanks,
Gilbert

Re: [mesos-mail] Re: [VOTE] Release Apache Mesos 1.5.2 (rc3)

[Gilbert Song]

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/58/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/58/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/58/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, Jan 16, 2019 at 11:04 AM Jie Yu  wrote:
> >
> >> +1
> >>
> >> make dist check on macOS Mojave
> >>
> >> On Tue, Jan 15, 2019 at 12:57 AM Gilbert Song 
> wrote:
> >>
> >>>  Hi all,
> >>>
> >>> Please vote on releasing the following candidate as Apache Mesos 1.5.2.
> >>>
> >>> 1.5.2 includes the following:
> >>>
> >>>
> 
> >>> *Announce major bug fixes here*
> >>> https://jira.apache.org/jira/issues/?filter=12345443
> >>>
> >>> The CHANGELOG for the release is available at:
> >>>
> >>>
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.5.2-rc3
> >>>
> >>>
> 
> >>>
> >>> The candidate for Mesos 1.5.2 release is available at:
> >>>
> https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc3/mesos-1.5.2.tar.gz
> >>>
> >>> The tag to be voted on is 1.5.2-rc3:
> >>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.5.2-rc3
> >>>
> >>> The SHA512 checksum of the tarball can be found at:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc3/mesos-1.5.2.tar.gz.sha512
> >>>
> >>> The signature of the tarball can be found at:
> >>>
> >>>
> https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc3/mesos-1.5.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 in a staging repository here:
> >>> https://repository.apache.org/content/repositories/orgapachemesos-1242
> >>>
> >>> Please vote on releasing this package as Apache Mesos 1.5.2!
> >>>
> >>> The vote is open until Fri Jan 18 00:52:44 PST 2019 and passes if a
> >>> majority of at least 3 +1 PMC votes are cast.
> >>>
> >>> [ ] +1 Release this package as Apache Mesos 1.5.2
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> Thanks,
> >>> Gilbert
> >>>
> >>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Apache Mesos Mail Lists" group.
> Visit this group at
> https://groups.google.com/a/mesosphere.io/group/mesos-mail/.
> For more options, visit https://groups.google.com/a/mesosphere.io/d/optout
> .
>

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

[Gilbert Song]

+1 (binding).

All tests passed except 5 failures (known flakiness) from our internal CI:

FLAG=CMake,label=mesos-ec2-centos-7
 mesos-ec2-centos-7-CMake.Mesos.CgroupsIsolatorTest.ROOT_CGROUPS_CFS_EnableCfs

FLAG=SSL,label=mesos-ec2-centos-7
 mesos-ec2-centos-7-SSL.MESOS_TESTS_ABORTED.xml.[empty]

FLAG=SSL,label=mesos-ec2-debian-9
 
mesos-ec2-debian-9-SSL.Mesos.FetcherCacheTest.CachedCustomOutputFileWithSubdirectory

FLAG=SSL,label=mesos-ec2-ubuntu-16.04
 
mesos-ec2-ubuntu-16.04-SSL.Mesos.CniIsolatorTest.ROOT_INTERNET_CURL_LaunchCommandTask

FLAG=SSL,label=mesos-ec2-centos-6
 
mesos-ec2-centos-6-SSL.Mesos.GarbageCollectorIntegrationTest.LongLivedDefaultExecutorRestart

-Gilbert

On Wed, Jan 16, 2019 at 2:24 PM Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI. Failing builds are due to missed SSL dep in the docker
> build file and a flaky test.
>
> *Revision*: d5678c3c5500cec72e22e775d9d048c55c128954
>
>- refs/tags/1.7.1-rc2
>
> Configuration Matrix gcc clang
> centos:7 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:16.04 --verbose --disable-libtool-wrappers
> --disable-parallel-test-execution --enable-libevent --enable-ssl autotools
> [image: Failed]
> 
> [image: Failed]
> 
> cmake
> [image: Failed]
> 
> [image: Failed]
> 
> --verbose --disable-libtool-wrappers --disable-parallel-test-execution
> autotools
> [image: Success]
> 
> [image: Failed]
> 
> 

[VOTE] Release Apache Mesos 1.5.2 (rc3)

[Gilbert Song]

 Hi all,

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

1.5.2 includes the following:

*Announce major bug fixes here*
https://jira.apache.org/jira/issues/?filter=12345443

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


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

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

The SHA512 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc3/mesos-1.5.2.tar.gz.sha512

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc3/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1242

Please vote on releasing this package as Apache Mesos 1.5.2!

The vote is open until Fri Jan 18 00:52:44 PST 2019 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Gilbert

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

[Gilbert Song]

Thanks, Chun!

I will cut rc3 sometime early next week.

On Tue, Nov 27, 2018 at 11:13 AM Chun-Hung Hsiao 
wrote:

> -1 for https://issues.apache.org/jira/browse/MESOS-8623
>
> I'm working on a fix.
>
> On Thu, Nov 22, 2018 at 1:40 PM Meng Zhu  wrote:
>
> > +1
> > make check on Ubuntu 18.04
> >
> > On Wed, Oct 31, 2018 at 4:26 PM Gilbert Song 
> > wrote:
> >
> > > Hi all,
> > >
> > > Please vote on releasing the following candidate as Apache Mesos 1.5.2.
> > >
> > > 1.5.2 includes the following:
> > >
> > >
> >
> 
> > > *Announce major bug fixes here*
> > >   * [MESOS-3790] - ZooKeeper connection should retry on `EAI_NONAME`.
> > >   * [MESOS-8128] - Make os::pipe file descriptors O_CLOEXEC.
> > >   * [MESOS-8418] - mesos-agent high cpu usage because of numerous
> > > /proc/mounts reads.
> > >   * [MESOS-8545] -
> > > AgentAPIStreamingTest.AttachInputToNestedContainerSession is flaky.
> > >   * [MESOS-8568] - Command checks should always call
> > > `WAIT_NESTED_CONTAINER` before `REMOVE_NESTED_CONTAINER`.
> > >   * [MESOS-8620] - Containers stuck in FETCHING possibly due to
> > > unresponsive server.
> > >   * [MESOS-8830] - Agent gc on old slave sandboxes could empty
> persistent
> > > volume data.
> > >   * [MESOS-8871] - Agent may fail to recover if the agent dies before
> > > image store cache checkpointed.
> > >   * [MESOS-8904] - Master crash when removing quota.
> > >   * [MESOS-8906] - `UriDiskProfileAdaptor` fails to update profile
> > > selectors.
> > >   * [MESOS-8907] - Docker image fetcher fails with HTTP/2.
> > >   * [MESOS-8917] - Agent leaking file descriptors into forked
> processes.
> > >   * [MESOS-8921] - Autotools don't work with newer OpenJDK versions.
> > >   * [MESOS-8935] - Quota limit "chopping" can lead to cpu-only and
> > > memory-only offers.
> > >   * [MESOS-8936] - Implement a Random Sorter for offer allocations.
> > >   * [MESOS-8942] - Master streaming API does not send (health) check
> > > updates for tasks.
> > >   * [MESOS-8945] - Master check failure due to CHECK_SOME(providerId).
> > >   * [MESOS-8947] - Improve the container preparing logging in
> > > IOSwitchboard and volume/secret isolator.
> > >   * [MESOS-8952] - process::await/collect n^2 performance issue.
> > >   * [MESOS-8963] - Executor crash trying to print container ID.
> > >   * [MESOS-8978] - Command executor calling setsid breaks the tty
> > support.
> > >   * [MESOS-8980] - mesos-slave can deadlock with docker pull.
> > >   * [MESOS-8986] - `slave.available()` in the allocator is expensive
> and
> > > drags down allocation performance.
> > >   * [MESOS-8987] - Master asks agent to shutdown upon auth errors.
> > >   * [MESOS-9024] - Mesos master segfaults with stack overflow under
> load.
> > >   * [MESOS-9049] - Agent GC could unmount a dangling persistent volume
> > > multiple times.
> > >   * [MESOS-9116] - Launch nested container session fails due to
> incorrect
> > > detection of `mnt` namespace of command executor's task.
> > >   * [MESOS-9125] - Port mapper CNI plugin might fail with "Resource
> > > temporarily unavailable".
> > >   * [MESOS-9127] - Port mapper CNI plugin might deadlock iptables on
> the
> > > agent.
> > >   * [MESOS-9131] - Health checks launching nested containers while a
> > > container is being destroyed lead to unkillable tasks.
> > >   * [MESOS-9142] - CNI detach might fail due to missing network config
> > > file.
> > >   * [MESOS-9144] - Master authentication handling leads to request
> > > amplification.
> > >   * [MESOS-9145] - Master has a fragile burned-in 5s authentication
> > > timeout.
> > >   * [MESOS-9146] - Agent has a fragile burn-in 5s authentication
> timeout.
> > >   * [MESOS-9147] - Agent and scheduler driver authentication retry
> > backoff
> > > time could overflow.
> > >   * [MESOS-9151] - Container stuck at ISOLATING due to FD leak.
> > >   * [MESOS-9170] - Zookeeper doesn't compile with newer gcc due to
> format
> > > error.
> > >   * [MESOS-9196] - Removing rootfs mounts may fail with EBUSY.
> > >   * [MESOS-9231] - `docker inspect` may return an unexpected result to
> > > Docker executor due to a race condition.
> > >   *

Re: mesos containerizer issue with v1.8.0: HTTP response Decoding failed

[Gilbert Song]

Hi Olivier and Adam,

This issue is already fixed by
https://issues.apache.org/jira/browse/MESOS-8907 which was merged and
backported 17 days ago. Please try it out and let me know.

More background contexts:

   1. http-parse does not support http/2:
   https://issues.apache.org/jira/browse/MESOS-8368
   2. curl enable http/2 by default after curl 7.47

- Gilbert

On Thu, Nov 8, 2018 at 2:33 PM Cecile, Adam  wrote:

> http-parser library is not updated anymore and does not support HTTP/2 so
> it's a dead end anyway
>
> Le 8 novembre 2018 10:17:20 GMT+01:00, Olivier Sallou <
> olivier.sal...@irisa.fr> a écrit :
>>
>>
>>
>> - Mail original -
>>
>>> De: "Olivier Sallou" 
>>> À: user@mesos.apache.org
>>> Envoyé: Mercredi 7 Novembre 2018 12:40:24
>>> Objet: Re: mesos containerizer issue with v1.8.0: HTTP response Decoding 
>>> failed
>>>
>>
>> On 11/7/18 11:54 AM, Cecile, Adam wrote:
>>>
  Hi,

  You might be hitting the same bug as I did (no HTTP/2 support in code
  pulling images for Mesos).
  https://issues.apache.org/jira/browse/MESOS-9364

>>>
>>>  adding some logs as suggested in your issue, error code is different,
>>>  getting "invalid constant string" error from http_parser error:
>>>
>>>
>>>   XX(INVALID_CONSTANT, "invalid constant string")
>>>
>>
>>
>> with additional debug, problem is related to http parser vs received answer 
>> from dockerhub. If I remove control on parsed data length vs body length  it 
>> works nicely (for test/debug only), so it may be a pb of response http 
>> compliance...
>> Anyway, this issue prevents download of docker images when using unified 
>> containerizer. As I am using code from master branch (latest), I can only 
>> hope it will be fixed before next release
>>
>>
>>
>>
>>>
>>>
  My report also include some code you can add in C++ code of the fetcher
  to retrieve the actual message coming from the http response parser 
 library.

  Regards, Adam.

  On 11/7/18 11:42 AM, Adam Cecile wrote:

> On 11/7/18 10:48 AM, Olivier Sallou wrote:
>
>> On 11/7/18 10:38 AM, Olivier Sallou wrote:
>>
>>>  Hi,
>>>
>>>  I installed mesos from source. It works fine with docker containerizer.
>>>
>>>  Howerver it fails with  unified containerizer at container start.
>>>
>>>  It used to work on a previous (older release) install. In the
>>>  meanwhile,
>>>  some system libs etc.. have been upgraded.
>>>
>>>  In logs I have the following:
>>>
>>>
>>>  I1107 09:32:48.707176 31983 containerizer.cpp:1280] Starting container
>>>  28f07a61-676a-4876-aae4-73598de90aae
>>>  E1107 09:32:49.683372 31986 slave.cpp:6168] Container
>>>  '28f07a61-676a-4876-aae4-73598de90aae' for executor '1-0' of framework
>>>  80fc2079-ba14-454b-8276-79fae090f8b3- failed to start: Failed to
>>>  decode HTTP responses: Decoding failed
>>>  HTTP/1.1 200 OK
>>>  Content-Type: application/json
>>>  Date: Wed, 07 Nov 2018 08:32:46 GMT
>>>  Transfer-Encoding: chunked
>>>  Strict-Transport-Security: max-age=31536000
>>>
>>>  105c
>>>  {"token":"eyJhbGciOiJSUzI1NiIsInR5cC...
>>>
>>>
>>>  Logs do not show the destination of the http request (a pull on docker
>>>  hub ? a request to master ? ...)
>>>
>>  I could increase some slave logging, and HTTP failure occurs with
>>  pulling of image:
>>
>>   I1107 10:45:56.689092 31987 registry_puller.cpp:286] Pulling image
>>  'library/centos:latest' from
>>  'docker-manifest://registry-1.docker.io:443library/centos?latest#https'
>>  to '/tmp/mesos/store/docker/staging/99WUh3'
>>   E1107 10:45:57.634601 31987 slave.cpp:6168] Container
>>  '48ea5811-3f97-41c1-b1a5-9a4416552545' for executor '6-0' of framework
>>  80fc2079-ba14-454b-8276-79fae090f8b3- failed to start: Failed to
>>  decode HTTP responses: Decoding failed
>>   HTTP/1.1 200 OK
>>   Content-Type: application/json
>>   Date: Wed, 07 Nov 2018 09:45:54 GMT
>>   Transfer-Encoding: chunked
>>   Strict-Transport-Security: max-age=31536000
>>
>>   
>>
>>
>>  so it seems there is an issue with mesos unified management with docker
>>  hub. Could it be related to libcurl version? (libcurl4 on my system). Is
>>  specific setup needed?
>>
>>
>>
>>  any idea on what could be wrong ? or how to get more debug info ?
>>>
>>>
>>>  Thanks
>>>
>>>
>>>  Olivier
>>>
>>>
>>> --
>>> Olivier Sallou
>>> Univ Rennes, Inria, CNRS, IRISA
>>> Irisa, Campus de Beaulieu
>>> F-35042 RENNES - FRANCE
>>> Tel: 02.99.84.71.95
>>>
>>> gpg key id: 4096R/326D8438  (keyring.debian.org)
>>> Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
>>>
>>
> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma
> 

Re: Propose to run debug container as the same user of its parent container by default

[Gilbert Song]

@James Peach  agree, for debug containers, the default
user should inherit from parent, while CLI toolings (e.g., task exec)
should provide an option `--root` (by setting the commandinfo user as root).

@Qian Zhang  @Benjamin Mahler  ,
if we step back, it seems to me we should extend the user inheritance for
all nested container (instead of just for debug container). Now the default
user for nested container is from the executor (see this patch
),
which does not make sense for 3rd level nested containers or further.

I would suggest that any type of nested container (debug container, check
container, nested container etc.), its user should just inherit from its
parent's user. This would not change the behavior of default executor,
potentially change behaviors for custom executor which support 3 level or
up nested.

- Gilbert

On Thu, Oct 25, 2018 at 9:51 AM Vinod Kone  wrote:

> Sounds good to me.
>
> If I understand correctly, you want to treat this is a bug and backport it
> to previous release branches? So, you are also asking whether backporting
> this bug will be considered a breaking change for any existing users?
>
> On Thu, Oct 25, 2018 at 11:46 AM James Peach  wrote:
>
>>
>>
>> On Oct 23, 2018, at 7:47 PM, Qian Zhang  wrote:
>>
>> Hi all,
>>
>> Currently when launching a debug container (e.g., via `dcos task exec` or
>> command health check) to debug a task, by default Mesos agent will use the
>> executor's user as the debug container's user. There are actually 2 cases:
>> 1. Command task: Since the command executor's user is same with command
>> task's user, so the debug container will be launched as the same user of
>> the command task.
>> 2. The task in a task group: The default executor's user is same with the
>> framework user, so in this case the debug container will be launched as the
>> same user of the framework rather than the task.
>>
>> Basically I think the behavior of case 1 is correct. For case 2, we may
>> run into a situation that the task is run as a user (e.g., root), but the
>> debug container used to debug that task is run as another user (e.g., a
>> normal user, suppose framework is run as a normal user), this may not be
>> what user expects.
>>
>> So I created MESOS-9332
>>  and propose to run
>> debug container as the same user of its parent container (i.e., the task to
>> be debugged) by default. Please let me know if you have any comments,
>> thanks!
>>
>>
>> This sounds like a sensible default to me. I can imagine for debug use
>> cases you might want to run the debug container as root or give it elevated
>> capabilities, but that should not be the default.
>>
>> J
>>
>

Re: Welcome Meng Zhu as PMC member and committer!

[Gilbert Song]

Well deserved, Meng!

On Wed, Oct 31, 2018 at 2:36 PM Benjamin Mahler  wrote:

> Please join me in welcoming Meng Zhu as a PMC member and committer!
>
> Meng has been active in the project for almost a year and has been very
> productive and collaborative. He is now one of the few people of
> understands the allocator code well, as well as the roadmap for this area
> of the project. He has also found and fixed bugs, and helped users in slack.
>
> Thanks for all your work so far Meng, I'm looking forward to more of your
> contributions in the project.
>
> Ben
>

[VOTE] Release Apache Mesos 1.5.2 (rc2)

[Gilbert Song]

 Hi all,

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

1.5.2 includes the following:

*Announce major bug fixes here*
  * [MESOS-3790] - ZooKeeper connection should retry on `EAI_NONAME`.
  * [MESOS-8128] - Make os::pipe file descriptors O_CLOEXEC.
  * [MESOS-8418] - mesos-agent high cpu usage because of numerous
/proc/mounts reads.
  * [MESOS-8545] -
AgentAPIStreamingTest.AttachInputToNestedContainerSession is flaky.
  * [MESOS-8568] - Command checks should always call
`WAIT_NESTED_CONTAINER` before `REMOVE_NESTED_CONTAINER`.
  * [MESOS-8620] - Containers stuck in FETCHING possibly due to
unresponsive server.
  * [MESOS-8830] - Agent gc on old slave sandboxes could empty persistent
volume data.
  * [MESOS-8871] - Agent may fail to recover if the agent dies before image
store cache checkpointed.
  * [MESOS-8904] - Master crash when removing quota.
  * [MESOS-8906] - `UriDiskProfileAdaptor` fails to update profile
selectors.
  * [MESOS-8907] - Docker image fetcher fails with HTTP/2.
  * [MESOS-8917] - Agent leaking file descriptors into forked processes.
  * [MESOS-8921] - Autotools don't work with newer OpenJDK versions.
  * [MESOS-8935] - Quota limit "chopping" can lead to cpu-only and
memory-only offers.
  * [MESOS-8936] - Implement a Random Sorter for offer allocations.
  * [MESOS-8942] - Master streaming API does not send (health) check
updates for tasks.
  * [MESOS-8945] - Master check failure due to CHECK_SOME(providerId).
  * [MESOS-8947] - Improve the container preparing logging in IOSwitchboard
and volume/secret isolator.
  * [MESOS-8952] - process::await/collect n^2 performance issue.
  * [MESOS-8963] - Executor crash trying to print container ID.
  * [MESOS-8978] - Command executor calling setsid breaks the tty support.
  * [MESOS-8980] - mesos-slave can deadlock with docker pull.
  * [MESOS-8986] - `slave.available()` in the allocator is expensive and
drags down allocation performance.
  * [MESOS-8987] - Master asks agent to shutdown upon auth errors.
  * [MESOS-9024] - Mesos master segfaults with stack overflow under load.
  * [MESOS-9049] - Agent GC could unmount a dangling persistent volume
multiple times.
  * [MESOS-9116] - Launch nested container session fails due to incorrect
detection of `mnt` namespace of command executor's task.
  * [MESOS-9125] - Port mapper CNI plugin might fail with "Resource
temporarily unavailable".
  * [MESOS-9127] - Port mapper CNI plugin might deadlock iptables on the
agent.
  * [MESOS-9131] - Health checks launching nested containers while a
container is being destroyed lead to unkillable tasks.
  * [MESOS-9142] - CNI detach might fail due to missing network config file.
  * [MESOS-9144] - Master authentication handling leads to request
amplification.
  * [MESOS-9145] - Master has a fragile burned-in 5s authentication timeout.
  * [MESOS-9146] - Agent has a fragile burn-in 5s authentication timeout.
  * [MESOS-9147] - Agent and scheduler driver authentication retry backoff
time could overflow.
  * [MESOS-9151] - Container stuck at ISOLATING due to FD leak.
  * [MESOS-9170] - Zookeeper doesn't compile with newer gcc due to format
error.
  * [MESOS-9196] - Removing rootfs mounts may fail with EBUSY.
  * [MESOS-9231] - `docker inspect` may return an unexpected result to
Docker executor due to a race condition.
  * [MESOS-9267] - Mesos agent crashes when CNI network is not configured
but used.
  * [MESOS-9279] - Docker Containerizer 'usage' call might be expensive if
mount table is big.
  * [MESOS-9283] - Docker containerizer actor can get backlogged with large
number of containers.
  * [MESOS-9305] - Create cgoup recursively to workaround systemd deleting
cgroups_root.
  * [MESOS-9308] - URI disk profile adaptor could deadlock.
  * [MESOS-9334] - Container stuck at ISOLATING state due to libevent poll
never returns.

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


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

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

The SHA512 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc2/mesos-1.5.2.tar.gz.sha512

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc2/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1239

Please vote on releasing this package as Apache Mesos 1.5.2!

The vote is open until Mon Nov  5 16:23:11 PDT 2018 and passes 

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

[Gilbert Song]

Ok, this issue has been fixed and backported. I will cut rc2 later today.

On Sat, Oct 27, 2018 at 9:53 PM Jie Yu  wrote:

> Gilbert, can we fix this and call another vote?
>
> Thanks,
> - Jie
>
> On Wed, Oct 24, 2018 at 12:45 PM Greg Mann  wrote:
>
>> Hmm I wonder if this is an issue on 1.5.1, or perhaps introduced by this
>> commit? https://github.com/apache/mesos/commit/902aa34b79
>>
>> On Wed, Oct 24, 2018 at 12:30 PM Vinod Kone  wrote:
>>
>>> -1
>>>
>>> Tested on ASF CI. Looks like Clang builds are failing with a build error.
>>> See example build output
>>> <
>>> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/55/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu:14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/console
>>> >
>>> below:
>>>
>>> libtool: compile:  clang++-3.5 -DPACKAGE_NAME=\"mesos\"
>>> -DPACKAGE_TARNAME=\"mesos\" -DPACKAGE_VERSION=\"1.5.2\"
>>> "-DPACKAGE_STRING=\"mesos 1.5.2\"" -DPACKAGE_BUGREPORT=\"\"
>>> -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" -DVERSION=\"1.5.2\"
>>> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
>>> -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
>>> -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
>>> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\"
>>> -DHAVE_CXX11=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 -DHAVE_PTHREAD=1
>>> -DHAVE_FTS_H=1 -DHAVE_APR_POOLS_H=1 -DHAVE_LIBAPR_1=1 -DHAVE_LIBCURL=1
>>> -DMESOS_HAS_JAVA=1 -DHAVE_EVENT2_EVENT_H=1 -DHAVE_LIBEVENT=1
>>> -DHAVE_EVENT2_THREAD_H=1 -DHAVE_LIBEVENT_PTHREADS=1 -DHAVE_LIBSASL2=1
>>> -DHAVE_OPENSSL_SSL_H=1 -DHAVE_EVENT2_BUFFEREVENT_SSL_H=1
>>> -DHAVE_LIBEVENT_OPENSSL=1 -DUSE_SSL_SOCKET=1 -DHAVE_SVN_VERSION_H=1
>>> -DHAVE_LIBSVN_SUBR_1=1 -DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1
>>> -DHAVE_ZLIB_H=1 -DHAVE_LIBZ=1 -DHAVE_PYTHON=\"2.7\"
>>> -DMESOS_HAS_PYTHON=1 -I. -I../../src -Werror
>>> -DLIBDIR=\"/mesos/mesos-1.5.2/_inst/lib\"
>>> -DPKGLIBEXECDIR=\"/mesos/mesos-1.5.2/_inst/libexec/mesos\"
>>> -DPKGDATADIR=\"/mesos/mesos-1.5.2/_inst/share/mesos\"
>>> -DPKGMODULEDIR=\"/mesos/mesos-1.5.2/_inst/lib/mesos/modules\"
>>> -I../../include -I../include -I../include/mesos -DPICOJSON_USE_INT64
>>> -D__STDC_FORMAT_MACROS -isystem ../3rdparty/boost-1.53.0 -isystem
>>> ../3rdparty/concurrentqueue-7b69a8f -I../3rdparty/elfio-3.2
>>> -I../3rdparty/glog-0.3.3/src -I../3rdparty/leveldb-1.19/include
>>> -I../../3rdparty/libprocess/include -I../3rdparty/nvml-352.79
>>> -I../3rdparty/picojson-1.3.0 -I../3rdparty/protobuf-3.5.0/src
>>> -I../../3rdparty/stout/include
>>> -I../3rdparty/zookeeper-3.4.8/src/c/include
>>> -I../3rdparty/zookeeper-3.4.8/src/c/generated -isystem
>>> /usr/include/subversion-1 -isystem /usr/include/apr-1 -isystem
>>> /usr/include/apr-1.0 -pthread -Wall -Wsign-compare -Wformat-security
>>> -fstack-protector-strong -fPIC -g1 -O0 -std=c++11 -MT
>>> slave/containerizer/libmesos_no_3rdparty_la-containerizer.lo -MD -MP
>>> -MF slave/containerizer/.deps/libmesos_no_3rdparty_la-containerizer.Tpo
>>> -c ../../src/slave/containerizer/containerizer.cpp  -fPIC -DPIC -o
>>> slave/containerizer/.libs/libmesos_no_3rdparty_la-containerizer.o
>>> In file included from ../../src/slave/http.cpp:30:
>>> In file included from ../../include/mesos/authorizer/authorizer.hpp:25:
>>> ../../3rdparty/libprocess/include/process/future.hpp:1089:3: error: no
>>> matching member function for call to 'set'
>>>   set(u);
>>>   ^~~
>>> ../../src/slave/http.cpp:3196:10: note: in instantiation of function
>>> template specialization
>>> 'process::Future::Future>> process::Future > >' requested here
>>>   return slave->containerizer->attach(containerId)
>>>  ^
>>> ../../3rdparty/libprocess/include/process/future.hpp:597:8: note:
>>> candidate function not viable: no known conversion from 'const
>>> process::Future >' to
>>> 'const process::http::Response' for 1st argument
>>>   bool set(const T& _t);
>>>^
>>> ../../3rdparty/libprocess/include/process/future.hpp:598:8: note:
>>> candidate function not viable: no known conversion from 'const
>&g

[VOTE] Release Apache Mesos 1.5.2 (rc1)

[Gilbert Song]

 Hi all,

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

1.5.2 includes the following:

  * [MESOS-3790] - ZooKeeper connection should retry on `EAI_NONAME`.
  * [MESOS-8128] - Make os::pipe file descriptors O_CLOEXEC.
  * [MESOS-8418] - mesos-agent high cpu usage because of numerous
/proc/mounts reads.
  * [MESOS-8545] -
AgentAPIStreamingTest.AttachInputToNestedContainerSession is flaky.
  * [MESOS-8568] - Command checks should always call
`WAIT_NESTED_CONTAINER` before `REMOVE_NESTED_CONTAINER`.
  * [MESOS-8620] - Containers stuck in FETCHING possibly due to
unresponsive server.
  * [MESOS-8830] - Agent gc on old slave sandboxes could empty persistent
volume data.
  * [MESOS-8871] - Agent may fail to recover if the agent dies before image
store cache checkpointed.
  * [MESOS-8904] - Master crash when removing quota.
  * [MESOS-8906] - `UriDiskProfileAdaptor` fails to update profile
selectors.
  * [MESOS-8917] - Agent leaking file descriptors into forked processes.
  * [MESOS-8921] - Autotools don't work with newer OpenJDK versions.
  * [MESOS-8935] - Quota limit "chopping" can lead to cpu-only and
memory-only offers.
  * [MESOS-8936] - Implement a Random Sorter for offer allocations.
  * [MESOS-8942] - Master streaming API does not send (health) check
updates for tasks.
  * [MESOS-8945] - Master check failure due to CHECK_SOME(providerId).
  * [MESOS-8947] - Improve the container preparing logging in IOSwitchboard
and volume/secret isolator.
  * [MESOS-8952] - process::await/collect n^2 performance issue.
  * [MESOS-8963] - Executor crash trying to print container ID.
  * [MESOS-8978] - Command executor calling setsid breaks the tty support.
  * [MESOS-8980] - mesos-slave can deadlock with docker pull.
  * [MESOS-8986] - `slave.available()` in the allocator is expensive and
drags down allocation performance.
  * [MESOS-8987] - Master asks agent to shutdown upon auth errors.
  * [MESOS-9024] - Mesos master segfaults with stack overflow under load.
  * [MESOS-9049] - Agent GC could unmount a dangling persistent volume
multiple times.
  * [MESOS-9116] - Launch nested container session fails due to incorrect
detection of `mnt` namespace of command executor's task.
  * [MESOS-9125] - Port mapper CNI plugin might fail with "Resource
temporarily unavailable".
  * [MESOS-9127] - Port mapper CNI plugin might deadlock iptables on the
agent.
  * [MESOS-9131] - Health checks launching nested containers while a
container is being destroyed lead to unkillable tasks.
  * [MESOS-9142] - CNI detach might fail due to missing network config file.
  * [MESOS-9144] - Master authentication handling leads to request
amplification.
  * [MESOS-9145] - Master has a fragile burned-in 5s authentication timeout.
  * [MESOS-9146] - Agent has a fragile burn-in 5s authentication timeout.
  * [MESOS-9147] - Agent and scheduler driver authentication retry backoff
time could overflow.
  * [MESOS-9151] - Container stuck at ISOLATING due to FD leak.
  * [MESOS-9170] - Zookeeper doesn't compile with newer gcc due to format
error.
  * [MESOS-9196] - Removing rootfs mounts may fail with EBUSY.
  * [MESOS-9231] - `docker inspect` may return an unexpected result to
Docker executor due to a race condition.
  * [MESOS-9267] - Mesos agent crashes when CNI network is not configured
but used.
  * [MESOS-9279] - Docker Containerizer 'usage' call might be expensive if
mount table is big.
  * [MESOS-9283] - Docker containerizer actor can get backlogged with large
number of containers.
  * [MESOS-9308] - URI disk profile adaptor could deadlock.

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


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

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

The SHA512 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc1/mesos-1.5.2.tar.gz.sha512

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.2-rc1/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1238

Please vote on releasing this package as Apache Mesos 1.5.2!

The vote is open until Wed Oct 24 23:59:00 PDT 2018 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Gilbert

Re: Propose to update the minimal supported Docker version in Mesos to Docker 1.8.0

[Gilbert Song]

We are considering to backport this fix to Mesos 1.6.x, 1.5.x and 1.4.x,
which means starting from 1.4.x your minimum docker version will be bumped
to Docker 1.8.0 (an old docker daemon version).

Please reply on this thread if this is a breaking change for you. Thank you!

- Gilbert

On Fri, Sep 28, 2018 at 7:01 PM Qian Zhang  wrote:

> Hi All,
>
> When I worked on MESOS-9231
> , I found the way that
> we
> run the `docker inspect` command seems not correct, we'd better specify
> `--type=container` for it, otherwise, `docker inspect` may return an object
> which is not a container (e.g., a volume).
>
> So I posted a patch  to add
> `--type=container` to the `docker inspect` command. However I found Docker
> started to support `--type=container` from 1.8.0, but our minimal supported
> Docker version is 1.0.0 (see here
> 
> for
> details). I think it does not make sense for us to support Docker 1.0.0
> which is too old, so I propose to update the minimal supported Docker
> version in Mesos to 1.8.0.
>
> Please let me know for any comments, thanks!
>
>
> Regards,
> Qian Zhang
>

Re: Backport Policy

[Gilbert Song]

Thanks for clarifying the backporting policy, BenM!

I totally agree with the changes proposed for the backporting policy, but I
realize two more scenarios that are more clear to me yet:

   - There are some bugs that are not fixable (due to legacy technical
   decisions), and we end up with fixing the issue by a semantic/behavior
   change in a new release. Do we expect this semantic/behavior change being
   backported?
   - There might be some bugs that root cause is unknown yet, but it did
   impact on a couple releases. If we decide to add some commits for debugging
   purpose (e.g., a new debugging endpoint, or more logging), should we also
   allow these patches to be backported?

For #2, I think we should do the backporting, but for #1, maybe more
discussion is needed since it relates to whether the user has to upgrade or
not.

Cheers,
Gilbert

On Tue, Jul 17, 2018 at 4:26 PM, Lawrence Rau  wrote:

> I don’t have a big stake in, however, one opinion is if a large commercial
> enterprise was using a specific release that is working the desire is often
> to only upgrade if necessary.  Necessary can be for a number of reasons
> including new features; however if a new feature is not needed the
> compelling reason to upgrade is to fix a specific problem that is causing
> issues.  Thus keeping a maintenance release stable is very important and
> reducing the chance for, while fixing one problem, introducing another.
>
> Often a clear classification of severity of the problem would dictate the
> need to make a change. (yes these can be subjective, but some guidance
> would be better than nothing).
>
> It might be good to give committers guidance on back porting things that
> have a high impact on improving a problem.  Fixing a crashing bug, fixing a
> degenerative performance issue, etc, where these issues have no easy/viable
> work around.  Nice to have fixes aren’t, always, worth updating to.
>
> There can be an argument to respond with a “then don’t upgrade” but if
> changing the release with “nice to have’s” and several point releases later
> when a critical bug is fixed then the org if forced to accept the risk of
> the nice to have’s.
>
> just an opinion.
> …larry
>
>
> On Jul 17, 2018, at 3:00 PM, Chun-Hung Hsiao 
> wrote:
>
> I just have a comment on a special case:
> If a fix for a flaky test is easy to backport,
> IMO we probably should backport it,
> otherwise if someone backports another critical fix in the future,
> it would take them extra effort to check all CI failures.
>
> On Mon, Jul 16, 2018 at 11:39 AM Vinod Kone  wrote:
>
>> I like how you summarized it Greg and I would vote for leaving the
>> decision
>> to the committer too. In addition to what others mentioned, I think
>> committer should've the responsibility because if things break in a point
>> release (after it is released), it is the committer and contributor who
>> are
>> on the hook to triage and fix it and not the release manager.
>>
>> Having said that, if "during" the release process (i.e., cutting an RC)
>> these backports cause delays for a release manager in getting the release
>> out (e.g., CI flakiness introduced due to backports), release manager
>> could
>> be the ultimate arbiter on whether such a backport should be reverted or
>> fixed by the committer/contributor. Hopefully such issues are caught much
>> before a release process is started (e.g., CI running against release
>> branches).
>>
>> On Mon, Jul 16, 2018 at 1:28 PM Jie Yu  wrote:
>>
>> > Greg, I like your idea of adding a prescriptive "policy" when evaluating
>> > whether a bug fix should be backported, and leave the decision to
>> committer
>> > (because they have the most context, and avoid a bottleneck in the
>> > process).
>> >
>> > - Jie
>> >
>> > On Mon, Jul 16, 2018 at 11:24 AM, Greg Mann  wrote:
>> >
>> > > My impression is that we have two opposing schools of thought here:
>> > >
>> > >1. Backport as little as possible, to avoid unforeseen consequences
>> > >2. Backport as much as proves practical, to eliminate bugs in
>> > >supported versions
>> > >
>> > > Do other people agree with this assessment?
>> > >
>> > > If so, how can we find common ground? One possible solution would be
>> to
>> > > leave the decision on backporting up to the committer, without
>> > specifying a
>> > > project-wide policy. This seems to be the status quo, and would lead
>> to
>> > > some variation across committers regarding what types of fixes are
>> > > backported. We could also choose to delegate the decision to the
>> release
>> > > manager; I favor leaving the decision with the committer, to eliminate
>> > the
>> > > burden on release managers.
>> > >
>> > > Here's a thought: rather than defining a prescriptive "policy" that we
>> > > expect committers to abide by, we could enumerate in the documentation
>> > the
>> > > competing concerns that we expect committers to consider when making
>> > > decisions on backports. The committing docs could read 

New Image Distribution Protocol and HDFS Image Fetching Design

[Gilbert Song]

Hi folks,

Here is the design doc for HDFS Image Fetching
.
It includes a custom protocol (Mesos Image Distribution Protocol
),
the corresponding Mesos support, and Image Store Deployment guide. The
Mesos Image Distribution Protocol is compatible for docker image v2 schema 1
 and schema 2
 (and potentially
compatible with OCI
).

This design doc aims for introducing an additional path to distribute
container images, compared to Docker Registry API. Please take a look and
leave comments.

Welcome to join the next Containerization WG meeting

on
July 12th, if you want to discuss in details.

Thanks,
Gilbert​​

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

[Gilbert Song]

 Hi all,

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

+1 (Binding)
--
*** Greg Mann
*** Jie Yu
*** Ben Mahler

There were no 0 or -1 votes.

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

The mesos-1.5.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,
Gilbert

[VOTE] Release Apache Mesos 1.5.1 (rc1)

[Gilbert Song]

Hi all,

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

1.5.1 includes the following:

* [MESOS-1720] - Slave should send exited executor message when the
executor is never launched.
* [MESOS-7742] - Race conditions in IOSwitchboard: listening on unix socket
and premature closing of the connection.
* [MESOS-8125] - Agent should properly handle recovering an executor when
its pid is reused.
* [MESOS-8411] - Killing a queued task can lead to the command executor
never terminating.
* [MESOS-8416] - CHECK failure if trying to recover nested containers but
the framework checkpointing is not enabled.
* [MESOS-8468] - `LAUNCH_GROUP` failure tears down the default executor.
* [MESOS-8488] - Docker bug can cause unkillable tasks.
* [MESOS-8510] - URI disk profile adaptor does not consider plugin type for
a profile.
* [MESOS-8536] - Pending offer operations on resource provider resources
not properly accounted for in allocator.
* [MESOS-8550] - Bug in `Master::detected()` leads to coredump in
`MasterZooKeeperTest.MasterInfoAddress`.
* [MESOS-8552] - CGROUPS_ROOT_PidNamespaceForward and
CGROUPS_ROOT_PidNamespaceBackward tests fail.
* [MESOS-8565] - Persistent volumes are not visible in Mesos UI when
launching a pod using default executor.
* [MESOS-8569] - Allow newline characters when decoding base64 strings in
stout.
* [MESOS-8574] - Docker executor makes no progress when 'docker inspect'
hangs.
* [MESOS-8575] - Improve discard handling for 'Docker::stop' and
'Docker::pull'.
* [MESOS-8576] - Improve discard handling of 'Docker::inspect()'.
* [MESOS-8577] - Destroy nested container if
`LAUNCH_NESTED_CONTAINER_SESSION` fails.
* [MESOS-8594] - Mesos master stack overflow in libprocess socket send loop.
* [MESOS-8598] - Allow empty resource provider selector in
`UriDiskProfileAdaptor`.
* [MESOS-8601] - Master crashes during slave reregistration after failover.
* [MESOS-8604] - Quota headroom tracking may be incorrect in the presence
of hierarchical reservation.
* [MESOS-8605] - Terminal task status update will not send if 'docker
inspect' is hung.
* [MESOS-8619] - Docker on Windows uses `USERPROFILE` instead of `HOME` for
credentials.
* [MESOS-8624] - Valid tasks may be explicitly dropped by agent due to race
conditions.
* [MESOS-8631] - Agent should be able to start a task with every CPU on a
Windows machine.
* [MESOS-8641] - Event stream could send heartbeat before subscribed.
* [MESOS-8646] - Agent should be able to resolve file names on open files.
* [MESOS-8651] - Potential memory leaks in the `volume/sandbox_path`
isolator.
* [MESOS-8741] - `Add` to sequence will not run if it races with sequence
destruction.
* [MESOS-8742] - Agent resource provider config API calls should be
idempotent.
* [MESOS-8786] - CgroupIsolatorProcess accesses subsystem processes
directly.
* [MESOS-8787] - RP-related API should be experimental.
* [MESOS-8876] - Normal exit of Docker container using rexray volume
results in TASK_FAILED.
* [MESOS-8881] - Enable epoll backend in libevent integration.
* [MESOS-8885] - Disable libevent debug mode.

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.5.1-rc1


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

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

The SHA512 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.1-rc1/mesos-1.5.1.tar.gz.sha512

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.1-rc1/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1224

Please vote on releasing this package as Apache Mesos 1.5.1!

The vote is open until Wed May 16 12:31:02 PDT 2018 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Gilbert

Re: Questions about secret handling in Mesos

[Gilbert Song]

IIUC, your assumptions are all correct.

@Kapil, could you please confirm? Maybe we could improve the document at
the next Docathon.

Gilbert

On Thu, Apr 19, 2018 at 10:57 AM, Zhitao Li  wrote:

> Hello,
>
> We at Uber plan to use volume/secret isolator to send secrets from Uber
> framework to Mesos agent.
>
> For this purpose, we are referring to these documents:
>
>- File based secrets design doc
> bMi5zBzMZmpc/edit#>
>and slides
> 20Management%20in%20Mesos.pdf>
>.
>- Apache Mesos secrets documentation
>
>
> Could you please confirm that the following assumptions are correct?
>
>- Mesos agent and master will never log the secret data at any logging
>level;
>- Mesos agent and master will never expose the secret data as part of
>any API response;
>- Mesos agent and master will never store the secret in any persistent
>storage, but only on tmpfs or ramfs;
>- When the secret is first downloaded on the mesos agent, it will be
>stored as "root" on the tmpfs/ramfs before being mounted in the
> container
>ramfs.
>
> If above assumptions are true, then I would like to see them documented in
> this as part of the Apache Mesos secrets documentation
> . Otherwise, we'd
> like to have a design discussion with maintainer of the isolator.
>
> We appreciate your help regarding this. Thanks!
>
> Regards,
> Aditya And Zhitao
>

Re: [mesos-mail] Re: Update the *Minimum Linux Kernel version* supported on Mesos

[Gilbert Song]

Hi all, FYI we landed this patch  to
avoid nested freezer cgroup support check for old kernel versions. Please
reply to this thread if you had concerns about this update.

- Gilbert

On Sun, Apr 8, 2018 at 12:18 AM, Alex Rukletsov  wrote:

> This does not seem to me as a disruptive change, so I'm +1.
>
> On Thu, Apr 5, 2018 at 6:36 PM, Jie Yu  wrote:
>
>> User namespaces require >= 3.12 (November 2013). Can we make that the
>>> minimum?
>>
>>
>> No, we need to support CentOS7 which uses 3.10 (some variant)
>>
>> - Jie
>>
>> On Thu, Apr 5, 2018 at 8:56 AM, James Peach  wrote:
>>
>>>
>>>
>>> > On Apr 5, 2018, at 5:00 AM, Andrei Budnik 
>>> wrote:
>>> >
>>> > Hi All,
>>> >
>>> > We would like to update minimum supported Linux kernel from 2.6.23 to
>>> > 2.6.28.
>>> > Linux kernel supports cgroups v1 starting from 2.6.24, but `freezer`
>>> cgroup
>>> > functionality was merged into 2.6.28, which supports nested containers.
>>>
>>> User namespaces require >= 3.12 (November 2013). Can we make that the
>>> minimum?
>>>
>>> J
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Apache Mesos Mail Lists" group.
> Visit this group at https://groups.google.com/a/mesosphere.io/group/mesos-
> mail/.
> For more options, visit https://groups.google.com/a/mesosphere.io/d/optout
> .
>

[Containerization WG] Sync Agenda for April 5th, 2018

[Gilbert Song]

Hi folks,

Tomorrow's WG meeting starts at 9 am PST. The agenda:

   - Volume Ownership use case update.
   - Mesos 1.6.0 will be cut around the end of April, let’s review our
   goals for 1.6 and update the spreadsheet.
   - Update the *Minimum Linux Kernel version* supported on Mesos to 2.6.28
   for nested freezer cgroup support.

Here is the link for Containerization WG:
https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugt
c2nHR89skFXSpU/edit#

Please join us via Zoom if you are interested: https://zoom.us/j/224160545

Thanks,
Gilbert

Re: This Month in Mesos - March 2018

[Gilbert Song]

Thanks for the awesome update, Greg!

- Gilbert

On Fri, Mar 30, 2018 at 6:20 PM, Vinod Kone  wrote:

> Thanks for the update Greg!
>
> Sent from my phone
>
> > On Mar 30, 2018, at 3:08 PM, Greg Mann  wrote:
> >
> > Oh hai there Apache Mesos Community!
> >
> > Back again with your monthly update on current events in the Mesosverse:
> >
> >
> > *Working Groups*
> >
> > Below you'll find a brief summary of the group meetings from this past
> > month, as well as some info about related work that's been happening in
> the
> > project. Working group meetings can be found on the Mesos community
> calendar
> > , and you should
> feel
> > free to add agenda items beforehand!
> >
> >
> > *API Working Group*
> >
> > [Agenda Doc
> >  IBWw1f_Ler6fLM/edit#>
> > ]
> >
> > Next Meeting: April 3 @ 11am PST
> >
> > In March we held the first two meetings of the new API working group!
> This
> > has brought about a revival of our perennial discussion on the preferred
> > Mesos release cadence; you can expect an updated release policy in our
> > documentation shortly. It's looking like the new policy will be in line
> > with what we have been doing in practice for the last few releases, so no
> > big changes there.
> >
> >
> > Zhitao also presented his ongoing work on new operations which will allow
> > the growing/shrinking of persistent volumes. You can find his design doc
> > here
> >  6EOaPzPtwYNVQUQ/edit>
> > .
> >
> >
> > *Containerization Working Group*
> >
> > [Agenda Doc
> >  c2nHR89skFXSpU/edit>
> > ]
> >
> > Next meeting: April 5 @ 9am PST
> >
> > Two big items in the containerization space this month:
> >
> >
> >   - Improvements to the Docker containerizer/executor to more gracefully
> >   handle bugs in the Docker daemon: MESOS-8572
> >   
> >   - Configurable network namespaces for nested containers: MESOS-8534
> >   
> >
> > *Community Working Group*
> >
> > [Agenda Doc
> >  3JG4f3qg-N5En-4ubg/edit#>
> > ]
> >
> > Next Meeting: April 9 @ 10:30am PST
> >
> > Community working group had a preliminary discussion about the next
> > quarterly doc-a-thon, and discussed the possibility of spinning up a new
> > Releases Working Group. We also discussed plans for the next MesosCon,
> and
> > how we may want to evolve that event going forward.
> >
> >
> > *Performance Working Group*
> >
> > [Agenda Doc
> >  4bodagrlNGCuQU/edit>
> > ]
> >
> > Next meeting: April 18 @ 10am PST
> >
> > We now have a performance dashboard
> >  rapidView=238=planning>
> > which lets you view tickets in ASF JIRA which have been marked as
> > performance-related - take a look!
> >
> >
> > Some additional copy elimination
> >  patches have been
> > merged, with more yet to come. The group also discussed the near-term
> > performance roadmap, which includes optimization of
> > authentication/authorization, master state computation, and the
> libprocess
> > HTTP code; see the agenda document for more details.
> >
> >
> >
> > Until next time,
> > -Greg
>

Mesos 1.5.1 Release

[Gilbert Song]

Folks,

I will be the release manager for Mesos 1.5.1 Release. Here is the JIRA
filter created for this release:
https://issues.apache.org/jira/issues/?filter=12343539

Please add the *JIRA target version as *1.5.1** and *mark it as *blocker**
if you have any issue that you need in 1.5.1, and reply to this thread.

Cheers,
Gilbert

Re: Communicate with a container while using Mesos unified container runtime

[Gilbert Song]

No, this feature based on Container Attach/Exec
<https://issues.apache.org/jira/browse/MESOS-6460>, which was included
starting from Mesos 1.2.0. I would recommend an upgrade to Mesos 1.4.1 or
1.3.2.

On Thu, Mar 22, 2018 at 5:46 PM, Karan Pradhan <karanprad...@gmail.com>
wrote:

>
>
> On 2018/03/22 23:16:06, Gilbert Song <gilb...@apache.org> wrote:
> > Hi Karan,
> >
> > It does not seem to me that launching more mesos containers would add
> more
> > overheads.
> >
> > If you want to achieve *docker exec* for debugging purpose, Mesos
> supports
> > that (not in Mesos CLI yet /cc Armand and Kevin), but you could still
> rely
> > on dc/os CLI
> > <https://docs.mesosphere.com/1.11/monitoring/debugging/task-exec/> to do
> > that given you have the taskId.
> >
> > Gilbert
> >
> > On Wed, Mar 21, 2018 at 12:08 PM, Karan Pradhan <karanprad...@gmail.com>
> > wrote:
> >
> > >
> > >
> > > On 2018/03/21 18:06:48, Gilbert Song <gilb...@apache.org> wrote:
> > > > Hi Karan,
> > > >
> > > > Before figuring out some ways to achieve this with Mesos, I would
> like to
> > > > better understand your use cases.
> > > >
> > > > Do you mean you rely on `docker attach/exec` to send commands to an
> > > > existing running container?
> > > >
> > > > Is there any reason that keeps you from launching a container for
> each
> > > > batch job?
> > > >
> > > > Gilbert
> > > >
> > > > On Wed, Mar 21, 2018 at 10:29 AM, karanprad...@gmail.com <
> > > > karanprad...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I was docker for running my batch job in which I would follow this
> > > > > approach:
> > > > >
> > > > > 1. Start the docker container
> > > > > 2. Send commands to the running Docker container with the help of
> > > docker
> > > > > python client for each batch of objects.
> > > > > 3. After all the batches are processed by the docker, shut down the
> > > > > container.
> > > > >
> > > > > I wanted to achieve the same with the help of Mesos and Marathon to
> > > spin
> > > > > up containers and submit commands per batch.
> > > > > But looking a the documents it looks like that this behavior is not
> > > > > achievable as when Mesos spin up a Docker container with the help
> of
> > > Mesos
> > > > > containerizer and docker/runtime isolation you can submit only one
> > > command
> > > > > after which the Sesos framework is killed.
> > > > >
> > > > > It would be great if someone could point me to a way to achieve
> this
> > > using
> > > > > Mesos containerizer?
> > > > >
> > > > > Thanks,
> > > > > Karan
> > > > >
> > > >
> > > Hi Gilbert,
> > > Thanks for taking time answering my question.
> > >
> > > Yes as you mentioned I use docker exec to run commands in the
> container.
> > > There is no particular reason why we don't run new docker. Would that
> add
> > > overhead if I had multiple batches which need to be processed?
> > >
> > > Do you know if docker exec is possible on a mesos container running
> with
> > > docker/runtime isolation?
> > >
> > > Thanks,
> > > Karan
> > >
> >
> Thanks Gilbert.
> I have built mesos 1.1.1 from the apache distribution, would dc/os cli
> work for this version too?
>

Re: Communicate with a container while using Mesos unified container runtime

[Gilbert Song]

Hi Karan,

It does not seem to me that launching more mesos containers would add more
overheads.

If you want to achieve *docker exec* for debugging purpose, Mesos supports
that (not in Mesos CLI yet /cc Armand and Kevin), but you could still rely
on dc/os CLI
<https://docs.mesosphere.com/1.11/monitoring/debugging/task-exec/> to do
that given you have the taskId.

Gilbert

On Wed, Mar 21, 2018 at 12:08 PM, Karan Pradhan <karanprad...@gmail.com>
wrote:

>
>
> On 2018/03/21 18:06:48, Gilbert Song <gilb...@apache.org> wrote:
> > Hi Karan,
> >
> > Before figuring out some ways to achieve this with Mesos, I would like to
> > better understand your use cases.
> >
> > Do you mean you rely on `docker attach/exec` to send commands to an
> > existing running container?
> >
> > Is there any reason that keeps you from launching a container for each
> > batch job?
> >
> > Gilbert
> >
> > On Wed, Mar 21, 2018 at 10:29 AM, karanprad...@gmail.com <
> > karanprad...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I was docker for running my batch job in which I would follow this
> > > approach:
> > >
> > > 1. Start the docker container
> > > 2. Send commands to the running Docker container with the help of
> docker
> > > python client for each batch of objects.
> > > 3. After all the batches are processed by the docker, shut down the
> > > container.
> > >
> > > I wanted to achieve the same with the help of Mesos and Marathon to
> spin
> > > up containers and submit commands per batch.
> > > But looking a the documents it looks like that this behavior is not
> > > achievable as when Mesos spin up a Docker container with the help of
> Mesos
> > > containerizer and docker/runtime isolation you can submit only one
> command
> > > after which the Sesos framework is killed.
> > >
> > > It would be great if someone could point me to a way to achieve this
> using
> > > Mesos containerizer?
> > >
> > > Thanks,
> > > Karan
> > >
> >
> Hi Gilbert,
> Thanks for taking time answering my question.
>
> Yes as you mentioned I use docker exec to run commands in the container.
> There is no particular reason why we don't run new docker. Would that add
> overhead if I had multiple batches which need to be processed?
>
> Do you know if docker exec is possible on a mesos container running with
> docker/runtime isolation?
>
> Thanks,
> Karan
>

Re: [Containerization WG] Call for Agenda, March 22nd, 2018

[Gilbert Song]

Seems like there is no agenda item for tomorrow's WG meeting. We will
cancel it at this time.

On Wed, Mar 21, 2018 at 10:30 AM, Gilbert Song <gilb...@apache.org> wrote:

> Folks,
>
> We are planning for a WG meeting tomorrow at 9 am PST.
>
> Please add any agenda item or topic that you like to discuss with the
> Containerization WG to the following list:
> https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugt
> c2nHR89skFXSpU/edit#heading=h.j7quoqe53vwr
>
> Thanks,
> Gilbert
>

Re: Communicate with a container while using Mesos unified container runtime

[Gilbert Song]

Hi Karan,

Before figuring out some ways to achieve this with Mesos, I would like to
better understand your use cases.

Do you mean you rely on `docker attach/exec` to send commands to an
existing running container?

Is there any reason that keeps you from launching a container for each
batch job?

Gilbert

On Wed, Mar 21, 2018 at 10:29 AM, karanprad...@gmail.com <
karanprad...@gmail.com> wrote:

> Hi,
>
> I was docker for running my batch job in which I would follow this
> approach:
>
> 1. Start the docker container
> 2. Send commands to the running Docker container with the help of docker
> python client for each batch of objects.
> 3. After all the batches are processed by the docker, shut down the
> container.
>
> I wanted to achieve the same with the help of Mesos and Marathon to spin
> up containers and submit commands per batch.
> But looking a the documents it looks like that this behavior is not
> achievable as when Mesos spin up a Docker container with the help of Mesos
> containerizer and docker/runtime isolation you can submit only one command
> after which the Sesos framework is killed.
>
> It would be great if someone could point me to a way to achieve this using
> Mesos containerizer?
>
> Thanks,
> Karan
>

[Containerization WG] Call for Agenda, March 22nd, 2018

[Gilbert Song]

Folks,

We are planning for a WG meeting tomorrow at 9 am PST.

Please add any agenda item or topic that you like to discuss with the
Containerization WG to the following list:
https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugtc2nHR89skFXSpU/edit#heading=h.j7quoqe53vwr

Thanks,
Gilbert

Welcome Zhitao Li as Mesos Committer and PMC Member

[Gilbert Song]

Hi,

I am excited to announce that the PMC has voted Zhitao Li as a new
committer and member of PMC for the Apache Mesos project. Please join me to
congratulate Zhitao!

Zhitao has been an active contributor to Mesos for one and a half years.
His main contributions include:

   - Designed and implemented Container Image Garbage Collection (MESOS-4945
   );
   - Designed and implemented part of the HTTP Operator API (MESOS-6007
   );
   - Reported and fixed a lot of bugs
   

   .

Zhitao spares no effort to improve the project quality and to propose
ideas. Thank you Zhitao for all contributions!

Here is his committer candidate checklist for your perusal:
https://docs.google.com/document/d/1HGz7iBdo1Q9z9c8fNRgNNLnj0XQ_PhDhjXLAfOx139s/

Congrats Zhitao!

Cheers,
Gilbert

Re: Welcome Chun-Hung Hsiao as Mesos Committer and PMC Member

[Gilbert Song]

Congrats, Chun!

It is great to have you in the community!

- Gilbert

On Sun, Mar 11, 2018 at 4:40 PM, Andrew Schwartzmeyer <
and...@schwartzmeyer.com> wrote:

> Congratulations Chun!
>
> I apologize for not also giving you a +1, as I certainly would have, but
> just discovered my mailing list isn't working. Just a heads up, don't let
> that happen to you too!
>
> I look forward to continuing to work with you.
>
> Cheers,
>
> Andy
>
>
> On 03/10/2018 9:14 pm, Jie Yu wrote:
>
>> Hi,
>>
>> I am happy to announce that the PMC has voted Chun-Hung Hsiao as a new
>> committer and member of PMC for the Apache Mesos project. Please join me
>> to
>> congratulate him!
>>
>> Chun has been an active contributor for the past year. His main
>> contributions to the project include:
>> * Designed and implemented gRPC client support to libprocess (MESOS-7749)
>> * Designed and implemented Storage Local Resource Provider (MESOS-7235,
>> MESOS-8374)
>> * Implemented part of the CSI support (MESOS-7235, MESOS-8374)
>>
>> Chun is friendly and humble, but also intelligent, insightful, and
>> opinionated. I am confident that he will be a great addition to our
>> committer pool. Thanks Chun for all your contributions to the project so
>> far!
>>
>> His committer checklist can be found here:
>> https://docs.google.com/document/d/1FjroAvjGa5NdP29zM7-2eg6t
>> LPAzQRMUmCorytdEI_U/edit?usp=sharing
>>
>> - Jie
>>
>
>

Re: Tasks may be explicitly dropped by agent in Mesos 1.5

[Gilbert Song]

Meng,

Could you double check if this is really an issue in Mesos 1.5.0 release?

MESOS-1720  was resolved
after the 1.5 release (rc-2) and it seems like
it is only at the master branch and 1.5.x branch (not 1.5.0).

Did I miss anything?

- Gilbert

On Thu, Mar 1, 2018 at 4:22 PM, Benjamin Mahler  wrote:

> Put another way, we currently don't guarantee in-order task delivery to
> the executor. Due to the changes for MESOS-1720, one special case of task
> re-ordering now leads to the re-ordered task being dropped (rather than
> delivered out-of-order as before). Technically, this is strictly better.
>
> However, we'd like to start guaranteeing in-order task delivery.
>
> On Thu, Mar 1, 2018 at 2:56 PM, Meng Zhu  wrote:
>
>> Hi all:
>>
>> TLDR: In Mesos 1.5, tasks may be explicitly dropped by the agent
>> if all three conditions are met:
>> (1) Several `LAUNCH_TASK` or `LAUNCH_GROUP` calls
>>  use the same executor.
>> (2) The executor currently does not exist on the agent.
>> (3) Due to some race conditions, these tasks are trying to launch
>> on the agent in a different order from their original launch order.
>>
>> In this case, tasks that are trying to launch on the agent
>> before the first task in the original order will be explicitly dropped by
>> the agent (TASK_DROPPED` or `TASK_LOST` will be sent)).
>>
>> This bug will be fixed in 1.5.1. It is tracked in
>> https://issues.apache.org/jira/browse/MESOS-8624
>>
>> 
>>
>> In https://issues.apache.org/jira/browse/MESOS-1720, we introduced an
>> ordering dependency between two `LAUNCH`/`LAUNCH_GROUP`
>> calls to a new executor. The master would specify that the first call is
>> the
>> one to launch a new executor through the `launch_executor` field in
>> `RunTaskMessage`/`RunTaskGroupMessage`, and the second one should
>> use the existing executor launched by the first one.
>>
>> On the agent side, running a task/task group goes through a series of
>> continuations, one is `collect()` on the future that unschedule
>> frameworks from
>> being GC'ed:
>> https://github.com/apache/mesos/blob/master/src/slave/slave.cpp#L2158
>> another is `collect()` on task authorization:
>> https://github.com/apache/mesos/blob/master/src/slave/slave.cpp#L2333
>> Since these `collect()` calls run on individual actors, the futures of the
>> `collect()` calls for two `LAUNCH`/`LAUNCH_GROUP` calls may return
>> out-of-order, even if the futures these two `collect()` wait for are
>> satisfied in
>> order (which is true in these two cases).
>>
>> As a result, under some race conditions (probably under some heavy load
>> conditions), tasks rely on the previous task to launch executor may
>> get processed before the task that is supposed to launch the executor
>> first, resulting in the tasks being explicitly dropped by the agent.
>>
>> -Meng
>>
>>
>>
>

Re: [RESULT][VOTE] Release Apache Mesos 1.5.0 (rc2)

[Gilbert Song]

Thanks to everyone who contributed to Mesos 1.5! The release blog is now up
at http://mesos.apache.org/blog/mesos-1-5-0-released/, and cross-posted on
Medium <https://medium.com/apache-mesos/apache-mesos-9c979d475d8b> in case
you prefer a shinier blog experience. Enjoy!

On Thu, Feb 8, 2018 at 8:18 AM, Gilbert Song <gilb...@apache.org> wrote:

> Hi all,
>
> The vote for Mesos 1.5.0 (rc2) has passed with the
> following votes.
>
> +1 (Binding)
> --
> Jie Yu
> Vinod Kone
> James Peach
> Andrew Schwartzmeyer
>
> +1 (Non-binding)
> --
> Zhitao Li
> Chun-Hung Hsiao
>
> There were no 0 or -1 votes.
>
> Please find the release at:
> https://dist.apache.org/repos/dist/release/mesos/1.5.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.5.0
>
> The mesos-1.5.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,
> Jie and Gilbert
>

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

[Gilbert Song]

Hi all,

The vote for Mesos 1.5.0 (rc2) has passed with the
following votes.

+1 (Binding)
--
Jie Yu
Vinod Kone
James Peach
Andrew Schwartzmeyer

+1 (Non-binding)
--
Zhitao Li
Chun-Hung Hsiao

There were no 0 or -1 votes.

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

The mesos-1.5.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,
Jie and Gilbert

[VOTE] Release Apache Mesos 1.5.0 (rc2)

[Gilbert Song]

Hi all,

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

1.5.0 includes the following:

  * Support Container Storage Interface (CSI).
  * Agent reconfiguration policy.
  * Auto GC docker images in Mesos Containerizer.
  * Standalone containers.
  * Support gRPC client.
  * Non-leading VOTING replica catch-up.


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


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.0-rc2/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1222

Please vote on releasing this package as Apache Mesos 1.5.0!

The vote is open until Tue Feb  6 17:35:16 PST 2018 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Jie and Gilbert

Re: This Month in Mesos - January 2018

[Gilbert Song]

Awesome, Greg!

On Tue, Jan 30, 2018 at 10:34 AM, Vinod Kone  wrote:

> Thanks Greg for the update!
>
>
> *Medium Posts*
>> Going forward, we'll be cross-posting Apache Mesos blog posts on Medium to
>> increase exposure, get feedback on engagement, and make it easier to
>> share.
>> Check out the new Apache Mesos publication > os> on
>> Medium for the latest content!
>>
>
>
> I'm really looking forward to this. As a reminder, if any one in the
> community wants to blog (cross post) about their use of Apache Mesos please
> reach out to us. We are always looking for great content!
>

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

[Gilbert Song]

Based on blocker issues list above and -1s, I will cut Mesos 1.5.0 rc2 once
MESOS-8481 <https://issues.apache.org/jira/browse/MESOS-8481> is resolved.

On Wed, Jan 24, 2018 at 10:40 AM, Michael Park <mp...@apache.org> wrote:

> -1 (binding) for https://issues.apache.org/jira/browse/MESOS-8481
> On Wed, Jan 24, 2018 at 10:34 AM James Peach <jor...@gmail.com> wrote:
>
> > +1
> >
> > Verified on CentOS 6 and Fedora 27
> >
> > > On Jan 22, 2018, at 7:15 PM, Gilbert Song <gilb...@apache.org> wrote:
> > >
> > > Hi all,
> > >
> > > Please vote on releasing the following candidate as Apache Mesos 1.5.0.
> > >
> > > 1.5.0 includes the following:
> > >
> > 
> 
> > >   * Support Container Storage Interface (CSI).
> > >   * Agent reconfiguration policy.
> > >   * Auto GC docker images in Mesos Containerizer.
> > >   * Standalone containers.
> > >   * Support gRPC client.
> > >   * Non-leading VOTING replica catch-up.
> > >
> > > 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.5.0-rc1
> > >
> > 
> 
> > >
> > > The candidate for Mesos 1.5.0 release is available at:
> > >
> > https://dist.apache.org/repos/dist/dev/mesos/1.5.0-rc1/
> mesos-1.5.0.tar.gz
> > >
> > > The tag to be voted on is 1.5.0-rc1:
> > > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=
> commit;h=1.5.0-rc1
> > >
> > > The MD5 checksum of the tarball can be found at:
> > >
> > https://dist.apache.org/repos/dist/dev/mesos/1.5.0-rc1/
> mesos-1.5.0.tar.gz.md5
> > >
> > > The signature of the tarball can be found at:
> > >
> > https://dist.apache.org/repos/dist/dev/mesos/1.5.0-rc1/
> mesos-1.5.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 in a staging repository here:
> > > https://repository.apache.org/content/repositories/orgapachemesos-1221
> > >
> > > Please vote on releasing this package as Apache Mesos 1.5.0!
> > >
> > > The vote is open until Thu Jan 25 18:24:36 PST 2018 and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> > >
> > > [ ] +1 Release this package as Apache Mesos 1.5.0
> > > [ ] -1 Do not release this package because ...
> > >
> > > Thanks,
> > > Jie and Gilbert
> >
> >
>

Re: Questions about Pods and the Mesos Containerizer

[Gilbert Song]

>
>
>-
>
>Is it possible to allocate a separate IP address per container in a
>pod?
>
> Right now nested containers share the network from their parent container
(pod). Do we have a specific use case that we need containers inside of a
taskgroup have different IP addresses?

- Gilbert

[VOTE] Release Apache Mesos 1.5.0 (rc1)

[Gilbert Song]

Hi all,

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

1.5.0 includes the following:

  * Support Container Storage Interface (CSI).
  * Agent reconfiguration policy.
  * Auto GC docker images in Mesos Containerizer.
  * Standalone containers.
  * Support gRPC client.
  * Non-leading VOTING replica catch-up.

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.5.0-rc1


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.5.0-rc1/mesos-1.5.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 in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1221

Please vote on releasing this package as Apache Mesos 1.5.0!

The vote is open until Thu Jan 25 18:24:36 PST 2018 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Jie and Gilbert

Mesos 1.5.0 Release

[Gilbert Song]

Folks,

It is time for Mesos 1.5.0 release. I am the release manager.

We plan to cut the rc1 in next couple weeks. Please start to wrap up
patches if you are contributing or shepherding any issue. If you expect any
particular JIRA for this new release, please set *Target Version* as "
*1.5.0"* and mark it as "*Blocker*" priority.

The dashboard for Mesos 1.5.0 will be posted in this thread soon.

Cheers,
Gilbert

Re: Quarterly Doc-a-thon Scheduling

[Gilbert Song]

Thank you, Judith! Will definitely join!

- Gilbert

On Tue, Nov 21, 2017 at 2:07 PM, Judith Malnick <jmaln...@mesosphere.io>
wrote:

> Hi Gilbert,
>
> The date I'm suggesting is January 11th (which is the second Thursday to
> occur in January). Hope it works for you :)
>
> Cheers,
> Judith
>
> --
> Get the Boomerang Email App <http://boomerangapp.com/mobile> on your phone
>
>
> ------
> On Mon, Nov 20, 2017 at 6:17 PM, Gilbert Song <gilb...@apache.org> wrote:
>

Re: Quarterly Doc-a-thon Scheduling

[Gilbert Song]

This is great! Thank you for scheduling the docathon, Judith!

BTW, do you mean January 2nd Tuesday or January 4th Thursday (asking since
I might be on a flight on the 2nd January)?

Cheers,
Gilbert

On Mon, Nov 20, 2017 at 11:00 AM, Vinod Kone  wrote:

> SGTM!
>
> On Mon, Nov 20, 2017 at 10:13 AM, Judith Malnick 
> wrote:
>
>> Hi all,
>>
>> Since the last doc-a-thon was so great, I'd love to get another on the
>> calendar for next quarter.
>>
>> The last one was on the 2nd Thursday of October, so It might make
>> sense to have the next one on the 2nd Thursday of January. (*January
>> 11th, 3-8pm Pacific time*).
>>
>> Does this date sound good to you? If I get many nos I'll follow up with a
>> doodle poll.
>>
>> All the best!
>> Judith
>>
>> --
>> Judith Malnick
>> Community Manager
>> 310-709-1517 <(310)%20709-1517>
>>
>
>

Re: [mesos-mail] Re: Welcome Greg Mann as a new committer and PMC member!

[Gilbert Song]

Congrats, Greg!

On Wed, Jun 14, 2017 at 11:46 AM, Sam  wrote:

> Congrats, well deserved
>
>
> Regards,
> Sam Chen | APJ Country Director | DC/OS Evangelist
>
> [image: Watch the Video]
> 
>  [image:
> .]Build and run modern apps
> at scale using DC/OS
> 
>
>
> On Jun 14, 2017, at 5:44 AM, Neil Conway  wrote:
>
> Congratulations, Greg!! Very well-deserved. Looking forward to
> continuing to work with you on the project.
>
> Neil
>
>
> On Tue, Jun 13, 2017 at 2:42 PM, Vinod Kone  wrote:
>
> Hi folks,
>
>
> Please welcome Greg Mann as the newest committer and PMC member of the
>
> Apache Mesos project.
>
>
> Greg has been an active contributor to the Mesos project for close to 2
>
> years now and has made many solid contributions. His biggest source code
>
> contribution to the project has been around adding authentication support
>
> for default executor. This was a major new feature that involved quite a
> few
>
> moving parts. Additionally, he also worked on improving the scheduler and
>
> executor APIs.
>
>
> Here is his more formal checklist for your perusal.
>
>
> https://docs.google.com/document/d/1S6U5OFVrl7ySmpJsfD4fJ3_
> R8JYRRc5spV0yKrpsGBw/edit
>
>
> Thanks,
>
> Vinod
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Apache Mesos Mail Lists" group.
> Visit this group at https://groups.google.com/a/mesosphere.io/group/mesos-
> mail/.
> For more options, visit https://groups.google.com/a/mesosphere.io/d/optout
> .
>

Docker Private Registry Credential per Container

[Gilbert Song]

Hi all,

Recently, we started working on support for docker private registry
credential per container in Mesos (MESOS-7088
). This feature aims to
allow users to specify a registry credential for an image at the first
class API.

Here is the link to the design doc:
https://docs.google.com/document/d/1kMXeJEuw4_adwyxqEjoMAdxRNzYHWrT_-eGd1uQLQEg/edit?usp=sharing

The design doc may not cover some pieces of implementation details, but it
should be sufficient to cover main ideas, user-facing API, and security
concerns. Comments will be absolutely welcome.

Thanks,
Gilbert

Re: Unified cgroups isolator

[Gilbert Song]

Awesome!

Kudos to @haosdent and @qianzhang!

On Tue, Sep 13, 2016 at 11:22 AM, haosdent  wrote:

> Really appreciate @qian and @jie's great helps on this! It makes us easier
> to add cgroups isolation for rest subsystem.
>
> Additionally, if you find any changes about unified cgroups isolator break
> your environment, please let us know. I would
> try to fix asap.
>
> On Wed, Sep 14, 2016 at 1:59 AM, Jie Yu  wrote:
>
>> Hi,
>>
>> We just merged the unified cgroups isolator. Huge shout out to @haosdent
>> and @qianzhang to make this happen!
>> https://issues.apache.org/jira/browse/MESOS-4697
>>
>> Just to give you some context. Previously, it's a huge pain to add a new
>> cgroups subsystem to Mesos because it requires creating a new isolator (a
>> lot of code duplication). Now, we merge all the subsystems into one single
>> isolator, that makes adding a new subsystem very easy.
>>
>> More importantly, the new cgroups isolator supports cgroups v2!
>>
>> - Jie
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Jenkins CI Plugin

[Gilbert Song]

Seems like Master::exited() is called for your jenkins frameworkId or PID.
Which
Mesos version are you using? It may possibly caused by network partition.
Are
you consistently getting this error?

Gilbert

On Fri, Sep 2, 2016 at 12:01 PM, June Taylor  wrote:

> Greetings,
>
> We're trying to use the Jenkins CI plugin
>  to start up
> tasks on our Mesos cluster.
>
> We're running into an error where the framework fails to register when
> starting up the Jenkins service, and this appears in the logs. Has anyone
> run into a similar issue? We are not sure what it means when it says the
> framework disconnected immediately after subscribing.
>
> Thanks!
>
> I0902 13:53:49.262558 114093 master.cpp:2231] Received SUBSCRIBE call for
> framework 'Jenkins Scheduler' at scheduler-fa208659-1cb1-4f7d-
> a17b-9a632bd4f0a9@127.0.1.1:35121
> I0902 13:53:49.262619 114093 master.cpp:2302] Subscribing framework
> Jenkins Scheduler with checkpointing disabled and capabilities [  ]
> I0902 13:53:49.262933 114093 master.cpp:1212] Framework
> 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins Scheduler) at
> scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:35121
> disconnected
> I0902 13:53:49.262964 114093 master.cpp:2527] Disconnecting framework
> 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins Scheduler) at
> scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:35121
> I0902 13:53:49.262974 114093 master.cpp:2551] Deactivating framework
> 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins Scheduler) at
> scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:35121
> I0902 13:53:49.263044 114093 master.cpp:1236] Giving framework
> 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins Scheduler) at
> scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:35121 0ns to
> failover
> I0902 13:53:49.264189 114088 master.cpp:5176] Framework failover timeout,
> removing framework 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins
> Scheduler) at scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:
> 35121
> I0902 13:53:49.264209 114088 master.cpp:5909] Removing framework
> 0c540ad0-a050-4c20-82df-7bd14ce95f51-28951 (Jenkins Scheduler) at
> scheduler-fa208659-1cb1-4f7d-a17b-9a632bd4f0a9@127.0.1.1:35121
>
> Thanks,
> June Taylor
> System Administrator, Minnesota Population Center
> University of Minnesota
>

The External Containerizer is Removed

[Gilbert Song]

Hello All,

FYI, as we discussed on the mailing list in Oct 2015 (link
)
and Apr 2016 (link

),
the External Containerizer was deprecated.

Now, we removed the External Containerizer from Mesos. Please see
MESOS-3370  for details.

Gilbert

Re: How could Mesos work with docker?

[Gilbert Song]

Yu,

Mesos supports docker images without using the docker daemon. This feature
is called Unified Containerizer, which was introduced since Mesos 0.28.
Please
follow this document to launch your containers:

http://mesos.apache.org/documentation/latest/container-image/

Feel free to join our slack channel 
if you have any question.

Gilbert

On Tue, Aug 9, 2016 at 7:13 AM, Yu Wei  wrote:

> Hi Tomek,
>
>
> Good point.
> Thanks very much for your help.
>
>
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
> --
> *From:* Tomek Janiszewski 
> *Sent:* Tuesday, August 9, 2016 10:06:28 PM
> *To:* d...@mesos.apache.org; user@mesos.apache.org
> *Subject:* Re: How could Mesos work with docker?
>
> Hi
>
> Docker support is described here http://mesos.apache.org/
> documentation/latest/docker-containerizer/
>
> Best
> Tomek
>
> wt., 9.08.2016 o 16:04 użytkownik Yu Wei  napisał:
>
>> Hi guys,
>>
>> I start learning mesos.
>>
>> How could mesos work with docker? Is there any document about this?
>>
>>
>> Any other advice?
>>
>>
>> Thx,
>>
>>
>> Jared, (韦煜）
>> Software developer
>> Interested in open source software, big data, Linux
>>
>

Re: Proposal: move content in Wiki to docs in code repo

[Gilbert Song]

+1.

At least I personally rarely touch the wiki.

Gilbert

On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing  wrote:

> +1
>
> It's good idea to collect and gather every thing in one single repo, would
> be easier for users to find out.
>
> Thanks & Best Wishes,
>
> Tom Xing(邢舟)
> Emerging Technology Institute, IBM China Software Development Lab
> --
> IBM China Software Development Laboratory (CSDL)
> Notes ID:Zhou Z Xing/China/IBM
> Phone :86-10-82450442
> e-Mail :xingz...@cn.ibm.com
> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei Wang
> West Road, Haidian District, Beijing, P.R.China 100193
> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>
>
> [image: Inactive hide details for Jie Yu ---2016-06-06 上午 11:29:42---Hi
> folks, I am proposing moving our content in Wiki (e.g., wor]Jie Yu
> ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our content in
> Wiki (e.g., working groups, release
>
> From: Jie Yu 
> To: mesos , "user@mesos.apache.org" <
> user@mesos.apache.org>
> Date: 2016-06-06 上午 11:29
> Subject: Proposal: move content in Wiki to docs in code repo
> --
>
>
>
> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
>
> What do you think?
>
> - Jie
>
>
>
>

Re: Mesos Web UI

[Gilbert Song]

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: Potential serious issue when upgrading OpenJDK8 to >= 8u77 with Debian / Ubuntu packaging

[Gilbert Song]

Hi Steven,

Thanks for reporting this serious issue. And yes, this is the right place
to notify
mesos users, which may potentially save many people a bunch of time while
collecting more review comments on your PR. Also, It would be helpful to
expose
the risk of upgrading OpenJDK to mesos users.

Again, thanks for your PR. I will dig into it tomorrow and comment on the
github
pull request.

Cheers,
Gilbert

On Wed, Apr 27, 2016 at 5:36 PM, Steven Schlansker <
sschlans...@opentable.com> wrote:

> Hello Mesos fans,
>
> I just wanted to alert you to a potentially disastrous incompatibility
> introduced in the last few OpenJDK packages released for the popular
> "openjdk-r" Ubuntu PPA.
>
> Per Debian bug 815475:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815475
>
> The OpenJDK packaging changed the virtual packages it provides.
> Notably, it no longer provides "java-runtime-headless", which Mesos
> depends on:
>
> http://bazaar.launchpad.net/%7Eopenjdk/openjdk/openjdk8/revision/672/debian/control
>
> This means that if you use the Mesosphere .deb packaging and the OpenJDK
> Ubuntu / Debian repos, when you upgrade from < 8u77 to >= 8u77, the Mesos
> package may be uninstalled.  If you happen to run Puppet, it calls apt with
> the "-f" force option by default, which will do all this without even
> telling you...
>
> I believe I have a fix here:
> https://github.com/mesosphere/mesos-deb-packaging/pull/77
>
> I would love critical review -- this surprised us and crippled our
> production clusters, and I got this out in a panic, so I am not 100% sure
> it is the right fix... hopefully this note saves someone else a really
> really
> bad day.
>
> Wishing package management a slow and painful death,
> Steven
>
> (PS... maybe this is good evidence that the Mesos project needs
> more support around understanding packaging and distribution management)
>
>

Re: FW: failure notice

[Gilbert Song]

Hi Aishwarya,

It would be helpful to find out the root cause if the agent log and sandbox
log can be attached:)

Gilbert

On Tue, Apr 26, 2016 at 5:17 AM, haosdent  wrote:

> Could you provide Mesos Agent log and stdout/stderr log?
>
> On Tue, Apr 26, 2016 at 7:53 PM, 
> wrote:
>
>> Hi,
>>
>> I tried running python application through Marathon GUI (
>> https://docs.docker.com/engine/userguide/containers/usingdocker/).The
>> application is delaying to deploy and  the task is failing .
>>
>> This what I am getting the error:-
>>
>> Task id hello-world.8b610fde-0b97-11e6-8964-fa163e724e71
>> State TASK_FAILED
>> Message Abnormal executor termination
>> Host 30.30.x.x
>> Timestamp 2016-04-26T10:13:38.815Z (an hour ago)
>> Version 2016-04-25T09:17:22.178Z (a day ago)
>> Mesos Details link<
>> http://30.30.x.x:5050/#/slaves/aab7953d-b2d1-4072-ad0a-c9e780ac2eb7-=S0/frameworks/a039103f-aab7-4f15-8578-0d52ac8f60e0-/executors/
>> >
>>
>> I'm able to run the docker containers (ex.Hello-world) through the cli of
>> the machine but I'm unable to get the application running in marathon GUI.
>>
>> Thank you,
>> Aishwarya Adyanthaya
>>
>>
>> 
>>
>> 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
>>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

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

[Gilbert Song]

Hi Kevin,

Please remove the the patch below from the list:
Implemented runtime isolator default cmd test (still under review).
https://reviews.apache.org/r/44469/

Because the bug was fixed by patch #44468, the test should not be
considered as a block. I am updating MESOS-4888 and move the test to a
separate JIRA.

Thanks,
Gilbert

On Tue, Mar 8, 2016 at 2:43 PM, Kevin Klues  wrote:

> Here are the list of reviews/patches that have been called out in this
> thread for inclusion in 0.28.0-rc2.  Some of them are still under
> review and will need to land by Thursday to be included.
>
> Are there others?
>
> Jie's container image documentation (submitted):
> commit 7de8cdd4d8ed1d222fa03ea0d8fa6740c4a9f84b
> https://reviews.apache.org/r/44414
>
> Restore Mesos' ability to extract Docker assigned IPs (still under review):
> https://reviews.apache.org/r/43093/
>
> Fixed the logic for default docker cmd case (submitted).
> commit e42f740ccb655c0478a3002c0b6fa90c1144f41c
> https://reviews.apache.org/r/44468/
>
> Implemented runtime isolator default cmd test (still under review).
> https://reviews.apache.org/r/44469/
>
> Fixed a bug that causes the task stuck in staging state (still under
> review).
> https://reviews.apache.org/r/44435/
>
> On Tue, Mar 8, 2016 at 10:30 AM, Kevin Klues  wrote:
> > Yes, will do.
> >
> > On Tue, Mar 8, 2016 at 10:26 AM, Vinod Kone 
> wrote:
> >> +kevin klues
> >>
> >> OK. I'm cancelling this vote since there are some show stopper issues
> that
> >> we need to cherry-pick. I'll cut another RC on Thursday.
> >>
> >> @shepherds: can you please make sure the blocker tickets are marked with
> >> fix version and that they land today or tomorrow?
> >>
> >> @kevin: since you have volunteered to help with the release, can you
> make
> >> sure we have a list of commits to cherry pick for rc2?
> >>
> >> Thanks,
> >>
> >>
> >> On Tue, Mar 8, 2016 at 12:05 AM, Shuai Lin 
> wrote:
> >>
> >>> Maybe also https://issues.apache.org/jira/browse/MESOS-4877 and
> >>> https://issues.apache.org/jira/browse/MESOS-4878 ?
> >>>
> >>>
> >>> On Tue, Mar 8, 2016 at 9:13 AM, Jie Yu  wrote:
> >>>
>  I'd like to fix https://issues.apache.org/jira/browse/MESOS-4888 as
> well
>  if you guys plan to cut another RC
> 
>  On Mon, Mar 7, 2016 at 10:16 AM, Daniel Osborne <
>  daniel.osbo...@metaswitch.com> wrote:
> 
> > -1
> >
> > If it doesn’t cause too much pain, I'm hoping we can squeeze a
> > relatively small patch which restores Mesos' ability to extract
> Docker
> > assigned IPs. This has been broken with Docker 1.10's release over
> a month
> > ago, and prevents service discovery and DNS from working.
> >
> > Mesos-4370: https://issues.apache.org/jira/browse/MESOS-4370
> > RB# 43093: https://reviews.apache.org/r/43093/
> >
> > I've built 0.28.0-rc1 with this patch and can confirm that it fixes
> it
> > as expected.
> >
> > Apologies for not bringing this to attention earlier.
> >
> > Thanks all,
> > Dan
> >
> > -Original Message-
> > From: Vinod Kone [mailto:vinodk...@apache.org]
> > Sent: Thursday, March 3, 2016 5:44 PM
> > To: dev ; user 
> > Subject: [VOTE] Release Apache Mesos 0.28.0 (rc1)
> >
> > Hi all,
> >
> >
> > Please vote on releasing the following candidate as Apache Mesos
> 0.28.0.
> >
> >
> > 0.28.0 includes the following:
> >
> >
> >
> 
> >
> >   * [MESOS-4343] - A new cgroups isolator for enabling the net_cls
> > subsystem in
> >
> > Linux. The cgroups/net_cls isolator allows operators to provide
> > network
> >
> >
> > performance isolation and network segmentation for containers
> within
> > a Mesos
> >
> > cluster. To enable the cgroups/net_cls isolator, append
> > `cgroups/net_cls` to
> >
> > the `--isolation` flag when starting the slave. Please refer to
> >
> >
> > docs/mesos-containerizer.md for more details.
> >
> >
> >
> >
> >
> >   * [MESOS-4687] - The implementation of scalar resource values
> (e.g.,
> > "2.5
> >
> >
> > CPUs") has changed. Mesos now reliably supports resources with
> up to
> > three
> >
> > decimal digits of precision (e.g., "2.501 CPUs"); resources with
> > more than
> >
> > three decimal digits of precision will be rounded. Internally,
> > resource math
> >
> > is now done using a fixed-point format that supports three
> decimal
> > digits of
> >
> > precision, and then converted to/from floating point for input
> and
> > output,
> >
> > respectively. Frameworks 

Re: Executors no longer inherit environment variables from the agent

[Gilbert Song]

Yes, `LIBPROCESS_IP` will be excepted from this change. We will still have
`LIBPROCESS_IP` set and passed to executors' environment, which is for the
case that DNS is not available on the slave.

Gilbert

On Tue, Mar 8, 2016 at 11:57 AM, Zhitao Li <zhitaoli...@gmail.com> wrote:

> Is LIBPROCESS_IP going to be an exception to this? Some executors are
> using this variable as an alternative of implementing their own IP
> detection logic AFAIK so this behavior would break them.
>
> On Tue, Mar 8, 2016 at 11:33 AM, Gilbert Song <gilb...@mesosphere.io>
> wrote:
>
>> Hi,
>>
>> TL;DR Executors will no longer inherit environment variables from the
>> agent by default in 0.30.
>>
>> Currently, executors are inheriting environment variables form the agent
>> in mesos containerizer by default. This is an unfortunate legacy behavior
>> and is insecure. If you do have environment variables that you want to pass
>> to the executors, you can set it explicitly by using the
>> `--executor_environment_variables` agent flag.
>>
>> Starting from 0.30, we will no longer allow executors to inherit
>> environment variables from the agent. In other words,
>> `--executor_environment_variables` will be set to “{}” by default. If you
>> do depend on the original behavior, please set
>> `--executor_environment_variables` flag explicitly.
>>
>> Let us know if you have any comments or concerns.
>>
>> Thanks,
>> Gilbert
>>
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Executors no longer inherit environment variables from the agent

[Gilbert Song]

Hi,

TL;DR Executors will no longer inherit environment variables from the agent
by default in 0.30.

Currently, executors are inheriting environment variables form the agent in
mesos containerizer by default. This is an unfortunate legacy behavior and
is insecure. If you do have environment variables that you want to pass to
the executors, you can set it explicitly by using the
`--executor_environment_variables` agent flag.

Starting from 0.30, we will no longer allow executors to inherit
environment variables from the agent. In other words,
`--executor_environment_variables` will be set to “{}” by default. If you
do depend on the original behavior, please set
`--executor_environment_variables` flag explicitly.

Let us know if you have any comments or concerns.

Thanks,
Gilbert