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

[Kapil Arya]

+1 (binding).

Internal CI succeeded. The binary deb/rpm packages for this RC can be found
here:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.7.0-rc3

On Fri, Sep 14, 2018 at 4:18 AM Alex Rukletsov  wrote:

> +1 (binding)
>
> Mesosphere's internal CI run with the aforementioned tag. Observed 4 flaky
> tests, 3 are known:
> https://issues.apache.org/jira/browse/MESOS-5048
> https://issues.apache.org/jira/browse/MESOS-8260
> https://issues.apache.org/jira/browse/MESOS-8951
>
> One has been introduced as part of adding GC to nested containers
> (MESOS-7947), which is disabled in the release:
> https://issues.apache.org/jira/browse/MESOS-9217
>
>
> On Tue, Sep 11, 2018 at 8:09 PM, Gastón Kleiman 
> wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 1.7.0.
>>
>>
>> 1.7.0 includes the following:
>>
>> 
>> * Performance Improvements:
>>   * Master `/state` endpoint: ~130% throughput improvement through
>> RapidJSON
>>   * Allocator: Improved allocator cycle significantly
>>   * Agent `/containers` endpoint: Fixed a performance issue
>>   * Agent container launch / destroy throughput is significantly improved
>> * Containerization:
>>   * **Experimental** Supported docker image tarball fetching from HDFS
>>   * Added new `cgroups/all` and `linux/devices` isolators
>>   * Added metrics for `network/cni` isolator and docker pull latency
>> * Windows:
>>   * Added support to libprocess for the Windows Thread Pool API
>> * Multi-Framework Workloads:
>>   * **Experimental** Added per-framework metrics to the master
>>   * A new weighted random sorter was added as an alternative to the DRF
>> sorter
>>
>> The CHANGELOG for the release is available at:
>>
>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.7.0-rc3
>>
>> 
>>
>> The candidate for Mesos 1.7.0 release is available at:
>> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc3/mesos-1.7.0.tar.gz
>>
>> The tag to be voted on is 1.7.0-rc3:
>> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.7.0-rc3
>>
>> The SHA512 checksum of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc3/mesos-1.7.0.tar.gz.sha512
>>
>> The signature of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc3/mesos-1.7.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-1234
>>
>> Please vote on releasing this package as Apache Mesos 1.7.0!
>>
>> The vote is open until Fri Sep 14 11:06:30 PDT 2018 and passes if a
>> majority of at least 3 +1 PMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Mesos 1.7.0
>> [ ] -1 Do not release this package because ...
>>
>> Thanks,
>>
>> Chun-Hung & Gastón
>>
>
>

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

[Kapil Arya]

Hi all,

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

+1 (Binding)
--
*** Ben Mahler
*** Kapil Arya
*** Alex Ruklestov

There were no 0 or -1 votes.

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

The mesos-1.4.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,
Anand and Kapil

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

[Kapil Arya]

+1 binding (internal CI).

The Apache CI failures reported by Vinod are all known flaky tests. I have
inserted the details inline.

Best,
Kapil

On Tue, Aug 14, 2018 at 11:03 AM Vinod Kone  wrote:

> I see some flaky tests in ASF CI, that I don't see already reported.
>
> @Kapil Arya   Can you take a look at
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53 and see
> if the flaky tests are due to bugs in test code and not source?
>
> *Revision*: 612ec2c63a68b4d5b60d1d864e6703fde1c2a023
>
>- refs/tags/1.4.2-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl autotools
> [image: Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >
>

Failed due to the timeout being too short -- leveldb took 11 seconds to
responds while the timeout expired at 10 seconds. It also looks like the
previous operation also took longer than expected potentially due to some
machine load at the time.

E0814 00:51:13.001557  8738 registrar.cpp:575] Registrar aborting:
Failed to update registry: Failed to perform store within 10secs
../../src/tests/registrar_tests.cpp:331: Failure
(registrar.apply( Owned( new MarkSlaveUnreachable(info1,
protobuf::getCurrentTime().failure(): Failed to update registry:
Failed to perform store within 10secs
I0814 00:51:18.990106  8743 leveldb.cpp:341] Persisting action (218
bytes) to leveldb took 11.656345772secs


ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> [image: Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >
> [image: Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >
>

> --verbose autotools

[image: Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53/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)/
> >
>

Failures because of known double-free corruption in test code due to
parallel manipulation of signal and control handler:
https://issues.apache.org/jira/browse/MESOS-8084



> cmake
> [image: Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/53/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/
> >
>

Failure due to known flaky: https://issues.apache.org/jira/browse/MESOS-7028

On Mon, Aug 13, 2018 at 7:41 PM Benjamin Mahler  wrote:

>
> > +1 (binding)
> >
> > make check passes on macOS 10.13.6 with Apple LLVM version 9.1.0
> > (clang-902.0.39.2).
> >
> > Thanks Kapil!
> >
> > On Wed, Aug 8, 2018 at 3:06 PM, Kapil Arya  wrote:
> >
> > > Hi all,
> > >
> > > Please vote on releasing the following candidate as Apache Mesos 1.4.2.
> > >
> > > 1.4.2 is a bug fix release. The CHANGELOG for the release is available
> > at:
> > > https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_
> > > plain;f=CHANGELOG;hb=1.4.2-rc1
> > >
> > > The candidate for Mesos 1.4.2 release is available at:
> > >
> >
> https://dist.apache.org/repos/dist/dev/mesos/1.4.2-rc1/mesos-1.4.2.tar.gz
> > >
> > > The tag to be voted on is 1.4.2-rc1:
> > > https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.4.2-rc1
> > >
> > > The SHA512 checksum of the tarball can be found at:
> > > https://dist.apache.org/repos/dist/dev/mesos/1.4.2-rc1/
> > > mesos-1.4.2.tar.gz.sha512
> > >
> > > The signature of the tarball can be found at:
> > > https://dist.apache.org/repos/dist/dev/mesos/1.4.2-rc1/
> > > mesos-1.4.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-1231
> > >
> > > Please vote on releasing this package as Apache Mesos 1.4.2!
> > >
> > > The vote is open until Sat Aug 11 11:59:59 PDT 2018 and passes if a
> > > majority of at least 3 +1 PMC votes are cast.
> > >
> > > [ ] +1 Release this package as Apache Mesos 1.4.2
> > > [ ] -1 Do not release this package because ...
> > >
> > > Thanks,
> > > Anand and Kapil
> > >
> >
>

[VOTE] Release Apache Mesos 1.4.2 (rc1)

[Kapil Arya]

Hi all,

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

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

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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.4.2-rc1/mesos-1.4.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-1231

Please vote on releasing this package as Apache Mesos 1.4.2!

The vote is open until Sat Aug 11 11:59:59 PDT 2018 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

Re: Getting write access to our GitHub repo

[Kapil Arya]

+1.

On Wed, Jun 20, 2018 at 10:59 PM Vinod Kone  wrote:

> Hi folks,
>
> Looks like ASF now supports  giving write
> access to committers for their GitHub mirrors, which means we can merge PRs
> directly on GitHub!
>
> FWICT, this requires us moving our repo to a new gitbox server by filing an
> INFRA ticket. We probably need to update our CI and other tooling that
> references our git repo directly, so there will be work involved on our end
> as well.
>
> This has been one of the long requested features from several committers,
> so I'm gauging interest to see if folks think we should go down this route
> (several projects seem to be already moving
> ) too.
>
> If there is enough interest, we could start a vote.
>
> Thanks,
> Vinod
>

Re: API working group

[Kapil Arya]

I'm interested in participating.

On Tue, Jan 30, 2018 at 1:42 PM, Vinod Kone  wrote:

> Hi folks,
>
> We've had good success with our containerization, performance and community
> working groups and so we would like to keep the momentum going and spin up
> new WGs as necessary.
>
> One of the recent proposals is to spin up a API working group to discuss
> about API changes and infrastructure.
>
> I'm sending this email to gauge interest from the broader community
> regarding this working group. Particularly I would like to know
> 1) Would you be interested in participating in the API WG?
> 2) Would you be interested in leading or co-leading the API WG?
>
> Please reply to this thread if interested.
>
> Thanks,
> Vinod
>

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

[Kapil Arya]

Hi all,

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

+1 (Binding)
--
*** Vinod Kone
*** Kapil Arya
*** Anand Mazumdar

There were no 0 or -1 votes.

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

The mesos-1.4.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,
Anand and Kapil

Re: .deb packages of mesos releases

[Kapil Arya]

On Tue, Nov 14, 2017 at 6:05 PM, Adam Cécile <adam.cec...@hitec.lu> wrote:

> Hi,
>
> It's usually considered as being a bad practise to put the Debian
> packaging itself into the upstream tree because it conflicts with the
> "real" packaging if it gets uploaded to Debian.
> But that's probably something we can figure out easily (maybe use another
> folder name and add hacky step in CI renaming the folder to Debian).
>

I'm not sure if I understand this. I used to maintain a debian package that
was uploaded to debian/ubuntu official repos and there we just kept a
`debian` folder inside the source tree (https://github.com/dmtcp/dmtcp).
With every upstream release, we updated the debian packaging to reflect an
updated version, etc. and that seemed to work fine. However, that was a
simpler package to maintain compared to Mesos, so I can imagine concerns
around that :).


> How would you do that ? Do you have workers running Debian/Ubuntu ? It's
> quite easy to create the package for any target (including foreign
> architectures, thanks to QEmu userland binary wrapper) but I don't think it
> can be done from a RHEL-based worker.
>
> Yeah, the ASF CI has Ubuntu workers that should work. However, to ensure a
sane environment, I would recommend using Debian/Ubuntu containers just
like we do for the CentOS builds. That way we can test/run it locally to
debug any issues and so on. Does that sound reasonable?



> Regards, Adam.
>
>
> On 11/14/2017 11:56 PM, Kapil Arya wrote:
>
> Hi Adam,
>
> I am wondering if you would have some time to bring your debian packaging
> into Mesos source tree. We can then use the ASF Jenkins CI to build and
> publish packages to bintray just like we started doing for CentOS 6/7? This
> will also allow the community to more actively participate in maintaining
> it in future.
>
> Best,
> Kapil
>
> On Wed, Sep 13, 2017 at 2:08 PM, Adam Cécile <adam.cec...@hitec.lu> wrote:
>
>> In case someone's interrested in, I added 1.1.3 debs on my repository:
>>
>> https://packages.le-vert.net/mesos/
>>
>>
>> On 09/09/2017 06:40 PM, Adam Cecile wrote:
>>
>> Hey,
>>
>> Well that's not really a problem, I can provide 1.1.x packages if your
>> interested in.
>>
>> Regards, Adam.
>>
>> On September 8, 2017 10:47:23 AM GMT+02:00, Tomek Janiszewski
>> <jani...@gmail.com> <jani...@gmail.com> wrote:
>>>
>>> @Adam Thanks for taking care of this. There is one problem, Mesos 1.1.3
>>> is missing in provided repository.
>>>
>>> @Kapil What is the status of official Apache Mesos packages? At Mesos
>>> Developer Community Meeting (Jan 26, 2017) you presented a proposal for
>>> this: https://youtu.be/m7WzKia68Rg
>>>
>>> wt., 5 wrz 2017 o 15:31 użytkownik Adam Cecile <adam.cec...@hitec.lu>
>>> napisał:
>>>
>>>> On 09/05/2017 11:55 AM, Oskar Jagodziński wrote:
>>>> > Hi all,
>>>> >
>>>> > What is standard interval between release of mesos package and
>>>> > 'official' .deb build by Mesosphere? Mesos 1.1.3 was released 11 days
>>>> > ago and there is no package at
>>>> > https://open.mesosphere.com/downloads/mesos/ only rc-packages
>>>> > https://open.mesosphere.com/downloads/mesos-rc/ are up to date.
>>>> >
>>>> Hello,
>>>>
>>>>
>>>> First, I like to make an important statement:
>>>>
>>>> *I'm not an official mesosphere guy*
>>>>
>>>> That being said, Mesosphere package are binary copy of CentOS built file
>>>> into a deb container. That's not what I call a Debian package at all and
>>>> I already had severe issue with that (libcurl-nss backed built which
>>>> does not support https on Debian-based system).
>>>>
>>>> For this reason, I create my own Mesos package, as a REAL debian
>>>> package, built from sources in a clean environment using pbuilder. I
>>>> also provide armhf and arm64 build because I've plan for that ;-)
>>>>
>>>> These package are in-use at three customers place and work just fine. I
>>>> provide multiple branches packages and build them with additional
>>>> network isolator using libnl and XFS disk isolator.
>>>>
>>>>
>>>> It's available there:
>>>>
>>>> https://packages.le-vert.net/mesos/
>>>>
>>>> Feel free to do what the f*** you want, use the repository directly,
>>>> sync it, rebuild debs from sources packages...
>>>>
>>>>
>>>> Regards, Adam.
>>>>
>>>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>>
>>
>
>

Re: .deb packages of mesos releases

[Kapil Arya]

Hi Adam,

I am wondering if you would have some time to bring your debian packaging
into Mesos source tree. We can then use the ASF Jenkins CI to build and
publish packages to bintray just like we started doing for CentOS 6/7? This
will also allow the community to more actively participate in maintaining
it in future.

Best,
Kapil

On Wed, Sep 13, 2017 at 2:08 PM, Adam Cécile  wrote:

> In case someone's interrested in, I added 1.1.3 debs on my repository:
>
> https://packages.le-vert.net/mesos/
>
>
> On 09/09/2017 06:40 PM, Adam Cecile wrote:
>
> Hey,
>
> Well that's not really a problem, I can provide 1.1.x packages if your
> interested in.
>
> Regards, Adam.
>
> On September 8, 2017 10:47:23 AM GMT+02:00, Tomek Janiszewski
>   wrote:
>>
>> @Adam Thanks for taking care of this. There is one problem, Mesos 1.1.3
>> is missing in provided repository.
>>
>> @Kapil What is the status of official Apache Mesos packages? At Mesos
>> Developer Community Meeting (Jan 26, 2017) you presented a proposal for
>> this: https://youtu.be/m7WzKia68Rg
>>
>> wt., 5 wrz 2017 o 15:31 użytkownik Adam Cecile 
>> napisał:
>>
>>> On 09/05/2017 11:55 AM, Oskar Jagodziński wrote:
>>> > Hi all,
>>> >
>>> > What is standard interval between release of mesos package and
>>> > 'official' .deb build by Mesosphere? Mesos 1.1.3 was released 11 days
>>> > ago and there is no package at
>>> > https://open.mesosphere.com/downloads/mesos/ only rc-packages
>>> > https://open.mesosphere.com/downloads/mesos-rc/ are up to date.
>>> >
>>> Hello,
>>>
>>>
>>> First, I like to make an important statement:
>>>
>>> *I'm not an official mesosphere guy*
>>>
>>> That being said, Mesosphere package are binary copy of CentOS built file
>>> into a deb container. That's not what I call a Debian package at all and
>>> I already had severe issue with that (libcurl-nss backed built which
>>> does not support https on Debian-based system).
>>>
>>> For this reason, I create my own Mesos package, as a REAL debian
>>> package, built from sources in a clean environment using pbuilder. I
>>> also provide armhf and arm64 build because I've plan for that ;-)
>>>
>>> These package are in-use at three customers place and work just fine. I
>>> provide multiple branches packages and build them with additional
>>> network isolator using libnl and XFS disk isolator.
>>>
>>>
>>> It's available there:
>>>
>>> https://packages.le-vert.net/mesos/
>>>
>>> Feel free to do what the f*** you want, use the repository directly,
>>> sync it, rebuild debs from sources packages...
>>>
>>>
>>> Regards, Adam.
>>>
>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
>

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

[Kapil Arya]

+1 (binding)

Mesosphere-internal CI with CentOS 6/7, Debian 8, Fedora 23, and Ubuntu
1[467].04.

On Mon, Nov 13, 2017 at 7:14 PM, Vinod Kone <vinodk...@apache.org> wrote:

> +1 (binding)
>
> Tested on ASF CI. Couple red failure builds were due to known flaky tests,
> one of which is already resolved on master.
>
>
> *Revision*: c844db9ac7c0cef59be87438c6781bfb71adcc42
>
>- refs/tags/1.4.1-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl autotools
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Not run]
> cmake
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%
> 7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Not run]
> --verbose autotools
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
> exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Not run]
> cmake
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%
> 3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> [image: Failed]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> cmake
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=-
> -verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> --verbose autotools
> [image: Success]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,
> label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> [image: Failed]
> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
> Release/43/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/43/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/43/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 Thu, Nov 9, 2017 at 6:27 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.4.1.
> >
> > 1.4.1 includes the follow

[VOTE] Release Apache Mesos 1.4.1 (rc1)

[Kapil Arya]

Hi all,

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

1.4.1 includes the following:

* [MESOS-7873] - Expose `ExecutorInfo.ContainerInfo.NetworkInfo` in Mesos
`state` endpoint.
* [MESOS-7921] - ProcessManager::resume sometimes crashes accessing
EventQueue.
* [MESOS-7964] - Heavy-duty GC makes the agent unresponsive.

* [MESOS-7968] - Handle `/proc/self/ns/pid_for_children` when parsing
available namespace.
* [MESOS-7969] - Handle cgroups v2 hierarchy when parsing
/proc/self/cgroups.
* [MESOS-7980] - Stout fails to compile with libc >= 2.26.

* [MESOS-8051] - Killing TASK_GROUP fail to kill some tasks.

* [MESOS-8080] - The default executor does not propagate missing task exit
status correctly.
* [MESOS-8090] - Mesos 1.4.0 crashes with 1.3.x agent with oversubscription

* [MESOS-8135] - Masters can lose track of tasks' executor IDs.

* [MESOS-8169] - Incorrect master validation forces executor IDs to be
globally unique.


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


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.4.1-rc1/mesos-1.4.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-1216

Please vote on releasing this package as Apache Mesos 1.4.1!

The vote is open until Monday, November 13, 2017, 11:59 PM EST and passes
if a majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

Binary RPM packages for CentOS

[Kapil Arya]

Hi All,

We have some updates regarding the binary RPM build/release process for
Mesos.

Here are some important bullet points:

* Jira: https://issues.apache.org/jira/browse/MESOS-7981
* The RPM packages are now built using a jenkins job [1] on the Apache CI.
* The build scripts are part of the Mesos source tree (support/packaging).
* Packages are distributed using bintray [2].
* Currently, we are using the mesos org under bintray. Once we have more
  confidence in the packages, we'll move under the apache org to benefit
from
  the superior resource limits.

Here are the steps to install the CentOS 7 packages from bintray:

*$* cat > /tmp/bintray-mesos-el.repo 

1.4.1 release

[Kapil Arya]

Please reply to this email if you have pending patches to be backported to
1.4.x as we are aiming to cut a release candidate for 1.4.1 early next week.

Thanks,
Anand and Kapil

Re: mesos.interface==1.4.0

[Kapil Arya]

> Kapil was this missed during the 1.4.0 release?


Yeah, it was missed due to PyPi deprecating the legacy API which our CI job
depended on. The failure to publish went unnoticed unfortunately and hence
the missing package. I have uploaded it manually for now and will fix the
CI script as well.

It seems to be in the
> release guide:
>
> http://mesos.apache.org/documentation/latest/release-guide/#updating-external-tooling
>
> On Sun, Oct 22, 2017 at 1:38 AM, Erb, Stephan  >
> wrote:
>
> > Hi,
> >
> > the mesos.interface==1.4.0 Python package is currently missing on PyPi (
> > https://pypi.python.org/pypi/mesos.interface/).
> >
> > Would be great if one of you could upload it.
> >
> > Thanks a lot,
> > Stephan
> >
>

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

[Kapil Arya]

Hi all,

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

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

There were no 0 or -1 votes.

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

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

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

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

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

Thanks,
Anand and Kapil

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

[Kapil Arya]

p=(docker%
>>> 7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>>> --verbose autotools
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>>> ease/42/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--
>>> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%
>>> 3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>>> ease/42/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: Failed]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>>> ease/42/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: Failed]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Rel
>>> ease/42/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=--
>>> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A1
>>> 4.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Sep 9, 2017 at 6:49 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>
>>> > Hi all,
>>> >
>>> > [NOTE: Starting with this RC candidate, we will not be "releasing" RC
>>> jar
>>> > files in the Maven release channel. This prevents polluting of the
>>> Maven
>>> > repositories with numerous RC tags. As before, you can continue to
>>> test the
>>> > release candidate using the Maven staging repository provided below.]
>>> >
>>> > Please vote on releasing the following candidate as Apache Mesos 1.4.0.
>>> >
>>> > 1.4.0 includes the following:
>>> > 
>>> > 
>>> >   * Ability to recover the agent ID after a host reboot.
>>> >   * File-based and image-pull secrets.
>>> >   * Linux ambient and bounding capabilities support.
>>> >   * Ability to efficiently measure disk usage without enforcing usage
>>> > constraints.
>>> >   * Hierarchical resource allocation roles. [EXPERIMENTAL]
>>> >
>>> > The CHANGELOG for the release is available at:
>>> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>>> > lain;f=CHANGELOG;hb=1.4.0-rc5
>>> > 
>>> 
>>> >
>>> >
>>> > The candidate for Mesos 1.4.0 release is available at:
>>> > https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc5/mesos
>>> -1.4.0.tar.gz
>>> >
>>> > The tag to be voted on is 1.4.0-rc5:
>>> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit
>>> ;h=1.4.0-rc5
>>> >
>>> > The MD5 checksum of the tarball can be found at:
>>> > https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc5/mesos
>>> > -1.4.0.tar.gz.md5
>>> >
>>> > The signature of the tarball can be found at:
>>> > https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc5/mesos
>>> > -1.4.0.tar.gz.asc
>>> >
>>> > The PGP key used to sign the release is here:
>>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>>> >
>>> > The JAR is up in Maven in a staging repository here:
>>> > https://repository.apache.org/content/repositories/orgapachemesos-1215
>>> >
>>> > Please vote on releasing this package as Apache Mesos 1.4.0!
>>> >
>>> > The vote is open until Wed Sep 13 11:59:00 PM EDT 2017 and passes if a
>>> > majority of at least 3 +1 PMC votes are cast.
>>> >
>>> > [ ] +1 Release this package as Apache Mesos 1.4.0
>>> > [ ] -1 Do not release this package because ...
>>> >
>>> > Thanks,
>>> > Anand and Kapil
>>> >
>>>
>>
>

[VOTE] Release Apache Mesos 1.4.0 (rc5)

[Kapil Arya]

Hi all,

[NOTE: Starting with this RC candidate, we will not be "releasing" RC jar
files in the Maven release channel. This prevents polluting of the Maven
repositories with numerous RC tags. As before, you can continue to test the
release candidate using the Maven staging repository provided below.]

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

1.4.0 includes the following:

  * Ability to recover the agent ID after a host reboot.
  * File-based and image-pull secrets.
  * Linux ambient and bounding capabilities support.
  * Ability to efficiently measure disk usage without enforcing usage
constraints.
  * Hierarchical resource allocation roles. [EXPERIMENTAL]

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



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

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

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

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

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

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

Please vote on releasing this package as Apache Mesos 1.4.0!

The vote is open until Wed Sep 13 11:59:00 PM EDT 2017 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

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

[Kapil Arya]

Looks like an important patch (https://reviews.apache.org/r/62053/) is
missing from this RC and so we're canceling the vote. We will
publish another RC shortly.

Sorry for the inconvenience.

Best,
Anand and Kapil

On Thu, Sep 7, 2017 at 1:57 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.4.0.
>
> 1.4.0 includes the following:
> 
>
>   * Ability to recover the agent ID after a host reboot.
>   * File-based and image-pull secrets.
>   * Linux ambient and bounding capabilities support.
>   * Ability to efficiently measure disk usage without enforcing usage
> constraints.
>   * Hierarchical resource allocation roles. [EXPERIMENTAL]
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.4.0-rc4
> 
>
>
> The candidate for Mesos 1.4.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc4/mesos-1.4.0.tar.gz
>
> The tag to be voted on is 1.4.0-rc4:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.4.0-rc4
>
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc4/
> mesos-1.4.0.tar.gz.md5
>
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc4/
> mesos-1.4.0.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1214
>
> Please vote on releasing this package as Apache Mesos 1.4.0!
>
> The vote is open until Mon Sep 11 11:59:00 PM EDT 2017 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 1.4.0
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Anand and Kapil
>

[VOTE] Release Apache Mesos 1.4.0 (rc4)

[Kapil Arya]

Hi all,

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

1.4.0 includes the following:


  * Ability to recover the agent ID after a host reboot.
  * File-based and image-pull secrets.
  * Linux ambient and bounding capabilities support.
  * Ability to efficiently measure disk usage without enforcing usage
constraints.
  * Hierarchical resource allocation roles. [EXPERIMENTAL]

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



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

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

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

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

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

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

Please vote on releasing this package as Apache Mesos 1.4.0!

The vote is open until Mon Sep 11 11:59:00 PM EDT 2017 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

[VOTE] Release Apache Mesos 1.4.0 (rc3)

[Kapil Arya]

Hi all,

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

1.4.0 includes the following:

  * Ability to recover the agent ID after a host reboot.
  * File-based and image-pull secrets.
  * Linux ambient and bounding capabilities support.
  * Ability to efficiently measure disk usage without enforcing usage
constraints.
  * Hierarchical resource allocation roles. [EXPERIMENTAL]

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



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

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

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

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

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

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

Please vote on releasing this package as Apache Mesos 1.4.0!

The vote is open until Thursday, Aug 31 11:59 PM PDT 2017 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

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

[Kapil Arya]

Hi All,

Due to a discrepancy in the CHANGELOG, we are retracting this release
candidate and will put out a new release candidate for voting in a little
while.

Best,
Anand and Kapil

On Mon, Aug 28, 2017 at 12:44 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.4.0.
>
>
> 1.4.0 includes the following:
> 
> 
>   * Ability to recover the agent ID after a host reboot.
>   * File-based and image-pull secrets.
>   * Linux ambient and bounding capabilities support.
>   * Ability to efficiently measure disk usage without enforcing usage
> constraints.
>   * Hierarchical resource allocation roles. [EXPERIMENTAL]
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.4.0-rc2
> 
>
>
> The candidate for Mesos 1.4.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc2/mesos-1.4.0.tar.gz
>
> The tag to be voted on is 1.4.0-rc2:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.4.0-rc2
>
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc2/
> mesos-1.4.0.tar.gz.md5
>
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.4.0-rc2/
> mesos-1.4.0.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1210
>
> Please vote on releasing this package as Apache Mesos 1.4.0!
>
> The vote is open until Thursday, Aug 31 11:59 AM PDT 2017 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 1.4.0
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Anand and Kapil
>

[VOTE] Release Apache Mesos 1.4.0 (rc2)

[Kapil Arya]

Hi all,

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


1.4.0 includes the following:


  * Ability to recover the agent ID after a host reboot.
  * File-based and image-pull secrets.
  * Linux ambient and bounding capabilities support.
  * Ability to efficiently measure disk usage without enforcing usage
constraints.
  * Hierarchical resource allocation roles. [EXPERIMENTAL]

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



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

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

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

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

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

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

Please vote on releasing this package as Apache Mesos 1.4.0!

The vote is open until Thursday, Aug 31 11:59 AM PDT 2017 and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

[VOTE] Release Apache Mesos 1.4.0 (rc1)

[Kapil Arya]

Hi all,

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

1.4.0 includes the following:


  * Ability to recover the agent ID after a host reboot.
  * File-based and image-pull secrets.
  * Linux ambient and bounding capabilities support.
  * Hierarchical resource allocation roles. [EXPERIMENTAL]

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



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

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

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

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

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

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

Please vote on releasing this package as Apache Mesos 1.4.0!

The vote is open until Wed. Aug 23, 2017 11:59:59 PM PDT, and passes if a
majority of at least 3 +1 PMC votes are cast.

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

Thanks,
Anand and Kapil

Re: Mesos 1.4.0

[Kapil Arya]

1.4.0 Update

We currently have 5 blockers, 4 critical, and 4 major issues.

To ramp up the process, we are cutting the 1.4.x branch today to allow
master to continue without affecting the 1.4.0 release. Please contact the
1.4.0 release managers for getting your changes cherry-picked from master
into the 1.4.x branch.

Best,
Anand and Kapil

On Thu, Jul 27, 2017 at 3:30 PM, Anand Mazumdar  wrote:

> Hello everyone,
>
> It's about time for Mesos 1.4.0 (somewhat late though, 1.3 rc1 was cut on
> 5/5) . Kapil would be the primary release manager and I would be the
> co-release manager.
>
> We expect to cut rc1 in the coming couple of weeks. Here's how you can
> help:
> - Set *Target Version = "1.4.0"* for anything that needs to go into this
> release. Anything not critical can wait for Mesos 1.5.
> - Upgrade release blockers to *"Blocker" priority*. Use "Critical" for
> any issues that would be painful (but possible) to ship Mesos 1.4 without.
>
> Mesos 1.4 release dashboard: https://issues.apache.org/jira/secure/
> Dashboard.jspa?selectPageId=12331513
>
> -anand
>

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

[Kapil Arya]

+1 Green build on internal CI.

The RC packages are available at:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.2.2-rc1

The following docker images based on Ubuntu 16.04 are also available:
* mesosphere/mesos:1.2.2-rc1
* mesosphere/mesos-master:1.2.2-rc1
* mesosphere/mesos-agent:1.2.2-rc1

Kapil

On Fri, Aug 4, 2017 at 8:12 PM, Adam Bordelon  wrote:

> Hello Mesos community,
>
> Please vote on releasing the following candidate as Apache Mesos 1.2.2.
>
> 1.2.2 includes the following:
> 
> 
>
>   * [MESOS-5187] - The filesystem/linux isolator does not set the
> permissions of the host_path.
>   * [MESOS-7252] - Need to fix resource check in long-lived framework.
>   * [MESOS-7540] - Add an agent flag for executor re-registration timeout.
>   * [MESOS-7546] - WAIT_NESTED_CONTAINER sometimes returns 404.
>   * [MESOS-7569] - Allow "old" executors with half-open connections to
> be preserved during agent upgrade / restart.
>   * [MESOS-7581] - Fix interference of external Boost installations
> when using some unbundled dependencies.
>   * [MESOS-7689] - Libprocess can crash on malformed request paths for
> libprocess messages.
>   * [MESOS-7690] - The agent can crash when an unknown executor tries
> to register.
>   * [MESOS-7703] - Mesos fails to exec a custom executor when no shell is
> used.
>   * [MESOS-7728] - Java HTTP adapter crashes JVM when leading master
> disconnects.
>   * [MESOS-7770] - Persistent volume might not be mounted if there is
> a sandbox volume whose source is the same as the target of the
> persistent volume.
>   * [MESOS-] - Agent failed to recover due to mount namespace
> leakage in Docker 1.12/1.13.
>   * [MESOS-7796] - LIBPROCESS_IP isn't passed on to the fetcher.
>   * [MESOS-7830] - Sandbox_path volume does not have ownership set
> correctly.
>
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.2.2-rc1
> 
> 
>
> The candidate for Mesos 1.2.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.2.2-rc1/mesos-1.2.2.tar.gz
>
> The tag to be voted on is 1.2.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.2.2-rc1
>
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.2.2-rc1/
> mesos-1.2.2.tar.gz.md5
>
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.2.2-rc1/
> mesos-1.2.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1202
>
> Please vote on releasing this package as Apache Mesos 1.2.2!
>
> The vote is open until at least Wed Aug 9 at 5pm PDT 2017 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 1.2.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
> -Adam and Alexander-
>

[RFC] File-based secrets

[Kapil Arya]

Hi All,

Recently, we started working on providing file-based secrets for Mesos
tasks (MESOS-7418 ). The
goal is to allow users to populate files within a task's environment with
contents fetched from a backend secret store. A new secret fetching module
interface is proposed to allow interaction with arbitrary third-party
secret stores.

Further details are covered in the following design doc:

https://docs.google.com/document/d/18raiiUfxTh-JBvjd6RyHe_TOScY87G_bMi5zBzMZmpc/

There might be a few minor pieces missing, but most of the design is there
and should answer most concerns. Please do raise an issue if you find
something missing. As always, any feedback is most welcome.

Best,
Kapil

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

[Kapil Arya]

+1 binding.

Built rpm/deb packages on internal build jobs. Packages are available here:
 http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.3-rc2

On Mon, Feb 6, 2017 at 3:01 PM, Adam Bordelon  wrote:

> +1 binding
>
> Tests passed against DC/OS 1.8.8 (prerelease), which is based on the Apache
> Mesos 1.0.x branch.
> https://github.com/dcos/dcos/pull/1210
>
> On Wed, Feb 1, 2017 at 10:01 AM, Vinod Kone  wrote:
>
> > +1 (binding)
> >
> > Tested on ASF CI
> >
> >
> > *Revision*: c673fdd00e7f93ab7844965435d57fd691fb4d8d
> >
> >- refs/tags/1.0.3-rc2
> >
> > Configuration Matrix gcc clang
> > centos:7 --verbose --enable-libevent --enable-ssl autotools
> > [image: Success]
> >  Release/26/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > cmake
> > [image: Success]
> >  Release/26/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%
> 7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > --verbose autotools
> > [image: Success]
> >  Release/26/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
> exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > cmake
> > [image: Success]
> >  Release/26/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%
> 3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> > [image: Success]
> >  Release/26/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Success]
> >  Release/26/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose%20--
> enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> 20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%
> 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > cmake
> > [image: Success]
> >  Release/26/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Success]
> >  Release/26/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=-
> -verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > --verbose autotools
> > [image: Success]
> >  Release/26/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,
> label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Success]
> >  Release/26/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]
> >  Release/26/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]
> >  Release/26/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 Tue, Jan 31, 2017 at 11:46 AM, Vinod Kone 
> wrote:
> >
> >> Hi all,
> >>
> >>
> >> Please vote on releasing the following candidate as Apache Mesos 1.0.3.
> >>
> >>
> >> 1.0.3 includes the following:
> >>
> >> 
> >> 
> >>
> >> * [MESOS-6052] - Unable to launch containers on CNI networks on
> >> CoreOS
> >>
> >> * [MESOS-6142] - Frameworks may RESERVE for an arbitrary role.
> 

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

[Kapil Arya]

+1 (binding).

Here is a link to the rpm/deb packages:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.1.0-rc1

Kapil

On Fri, Oct 21, 2016 at 5:37 PM, Zhitao Li  wrote:

> +1 (non-binding)
>
> make check passes on Debian 8.
>
> Docker related tests pass.
>
> Several root required tests failed due to special machine setup on AWS,
> but not seems severe.
>
> Integration tests works for Aurora and DockerContainerizer in small
> cluster.
>
>
> On Wed, Oct 19, 2016 at 11:49 AM, Vinod Kone  wrote:
>
>> +1 (binding)
>>
>> Tested on ASF CI.
>>
>>
>> *Revision*: c2cb47f78f1d99630b133b00bdd4c9d4c523c02b
>>
>>- refs/tags/1.1.0-rc1
>>
>> Configuration Matrix gcc clang
>> centos:7 --verbose --enable-libevent --enable-ssl autotools
>> [image: Success]
>> 
>> [image: Not run]
>> cmake
>> [image: Success]
>> 
>> [image: Not run]
>> --verbose autotools
>> [image: Success]
>> 
>> [image: Not run]
>> cmake
>> [image: Success]
>> 
>> [image: Not run]
>> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
>> [image: Success]
>> 
>> [image: Success]
>> 
>> cmake
>> [image: Success]
>> 
>> [image: Success]
>> 
>> --verbose autotools
>> [image: Success]
>> 
>> [image: Success]
>> 
>> cmake
>> [image: Success]
>> 
>> [image: Success]
>> 
>>
>> On Tue, Oct 18, 2016 at 1:01 PM, Till Toenshoff  wrote:
>>
>>> Hi all,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 1.1.0.
>>>
>>>
>>> 1.1.0 includes the following:
>>> 
>>> 
>>>   * [MESOS-2449] - **Experimental** support for launching a group of
>>> tasks
>>> via a new `LAUNCH_GROUP` Offer operation. Mesos will guarantee that
>>> either
>>> all tasks or none of the tasks in the group are delivered to the
>>> executor.
>>> Executors receive the task group via a new `LAUNCH_GROUP` event.
>>>
>>>   * [MESOS-2533] - **Experimental** support for HTTP and HTTPS health
>>> checks.
>>> Executors may now use 

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

[Kapil Arya]

+1 (binding)

You can find the rpm/deb packages here:
  http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.1-rc1

The following docker tags (built off of ubuntu 14.04) are also available:
mesosphere/mesos:1.0.1-rc1
mesosphere/mesos-master:1.0.1-rc1
mesosphere/mesos-slave:1.0.1-rc1

Kapil

On Fri, Aug 12, 2016 at 4:39 PM, Alex Rukletsov  wrote:

> +1 (binding)
>
> make check on Mac OS 10.11.6 with apple clang-703.0.31.
>
> DockerFetcherPluginTest.INTERNET_CURL_FetchImage is flaky (MESOS-4570),
> but
> this does not seem to be a regression or a blocker.
>
> On Fri, Aug 12, 2016 at 10:30 PM, Radoslaw Gruchalski <
> ra...@gruchalski.com>
> wrote:
>
> > I am trying to build Mesos 1.0.1 for Centos 7 in a Docker container but
> > I'm hitting this: https://issues.apache.org/jira/browse/MESOS-5925.
> >
> > Kind regards,
> >
> > Radek Gruchalski
> > ra...@gruchalski.com
> > +4917685656526
> >
> > *Confidentiality:*
> > This communication is intended for the above-named person and may be
> > confidential and/or legally privileged.
> > If it has come to you in error you must take no action based on it, nor
> > must you copy or show it to anyone; please delete/destroy and inform the
> > sender immediately.
> >
> > On Thu, Aug 11, 2016 at 2:32 AM, Vinod Kone 
> wrote:
> >
> >> Hi all,
> >>
> >>
> >> Please vote on releasing the following candidate as Apache Mesos 1.0.1.
> >>
> >>
> >> The CHANGELOG for the release is available at:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
> >> lain;f=CHANGELOG;hb=1.0.1-rc1
> >>
> >> 
> >> 
> >>
> >>
> >> The candidate for Mesos 1.0.1 release is available at:
> >>
> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/
> mesos-1.0.1.tar.gz
> >>
> >>
> >> The tag to be voted on is 1.0.1-rc1:
> >>
> >> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=
> commit;h=1.0.1-rc1
> >>
> >>
> >> The MD5 checksum of the tarball can be found at:
> >>
> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/mesos
> >> -1.0.1.tar.gz.md5
> >>
> >>
> >> The signature of the tarball can be found at:
> >>
> >> https://dist.apache.org/repos/dist/dev/mesos/1.0.1-rc1/mesos
> >> -1.0.1.tar.gz.asc
> >>
> >>
> >> The PGP key used to sign the release is here:
> >>
> >> https://dist.apache.org/repos/dist/release/mesos/KEYS
> >>
> >>
> >> The JAR is up in Maven in a staging repository here:
> >>
> >> https://repository.apache.org/content/repositories/orgapachemesos-1155
> >>
> >>
> >> Please vote on releasing this package as Apache Mesos 1.0.1!
> >>
> >>
> >> The vote is open until Mon Aug 15 17:29:33 PDT 2016 and passes if a
> >> majority of at least 3 +1 PMC votes are cast.
> >>
> >>
> >> [ ] +1 Release this package as Apache Mesos 1.0.1
> >>
> >> [ ] -1 Do not release this package because ...
> >>
> >>
> >> Thanks,
> >>
> >
> >
>

Re: Anonymous modules

[Kapil Arya]

It hasn't been removed, but was moved around a bit:
https://github.com/apache/mesos/blob/master/src/master/main.cpp#L334



On Tue, Aug 9, 2016 at 5:07 PM, Marco Massenzio 
wrote:

> Hi folks,
>
> I've recently updated my repo to the 1.0.0 release and noticed that the
> code in main.cpp that used to run the anonymous modules is now gone.
>
> Before I embark on a wild goose chase to find it, could someone please let
> me know if they are still supported?
> (if they aren't I have clearly missed the memo - sorry about that!)
>
> Thanks in advance for any help.
> --
> *Marco Massenzio*
> http://codetrips.com
>

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

[Kapil Arya]

You can find the 1.0.0 rpm/deb packages at:

http://open.mesosphere.com/downloads/mesos/#apache-mesos-1.0.0


And here are the corresponding docker images based off of Ubuntu 14.04:

mesosphere/mesos:1.0.0
mesosphere/mesos-master:1.0.0
mesosphere/mesos-slave:1.0.0

Kapil

On Wed, Jul 27, 2016 at 2:52 PM, Jeff Schroeder <jeffschroe...@computer.org>
wrote:

> Small nit but can you s/experimnental/experimental/ under the "Storage"
> header in the release post please?
>
> Great work otherwise everyone!
>
>
> On Wednesday, July 27, 2016, Vinod Kone <vinodk...@apache.org> wrote:
>
>> Hi all,
>>
>> The vote for Mesos 1.0.0 (rc4) has passed with the following votes.
>>
>>
>> +1 (Binding)
>>
>> --
>>
>> Kapil Arya
>>
>> Jie Yu
>>
>> Benjamin Mahler
>>
>>
>> +1 (Non-binding)
>>
>> --
>>
>> Haosdent
>>
>> Greg Mann
>>
>> Zhitao Li
>>
>>
>> +0
>>
>> -
>>
>> Yan Xu
>>
>>
>> There were no  -1 votes.
>>
>>
>> *NOTE: There were a couple known issues [MESOS-5911
>> <https://issues.apache.org/jira/browse/MESOS-5911>, MESOS-5913
>> <https://issues.apache.org/jira/browse/MESOS-5913>] that couldn't be fixed
>> in time for the 1.0. We plan to do a patch release to fix these ASAP.*
>>
>>
>> Please find the release at:
>>
>> https://dist.apache.org/repos/dist/release/mesos/1.0.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.0.0
>>
>>
>> The mesos-1.0.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,
>>
>> On Fri, Jul 22, 2016 at 10:40 PM, Vinod Kone <vinodk...@apache.org>
>> wrote:
>>
>>> Hi all,
>>>
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>>>
>>> *The vote is open until Tue Jul 25 11:00:00 PDT 2016 and passes if a
>>> majority of at least 3 +1 PMC votes are cast.*
>>>
>>> 1.0.0 includes the following:
>>>
>>>
>>> 
>>>
>>>   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>>>
>>>
>>>
>>>
>>>
>>>   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>>> APIs. These
>>>
>>> APIs let operators and services (monitoring, load balancers) send
>>> HTTP
>>>
>>> requests to '/api/v1' endpoint on master or agent. See
>>>
>>>
>>> `docs/operator-http-api.md` for details.
>>>
>>>
>>>
>>>
>>>
>>>   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>>> isolator
>>>
>>> has been added to isolate disk resources more efficiently. Please
>>> refer to
>>>
>>> docs/mesos-containerizer.md for more details.
>>>
>>>
>>>
>>>
>>>
>>>   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
>>> added a
>>>
>>> new isolator 'docker/volume' which allows users to use external
>>> volumes in
>>>
>>> Mesos containerizer. Currently, the isolator interacts with the
>>> Docker
>>>
>>> volume plugins using a tool called 'dvdcli'. By speaking the Docker
>>> volume
>>>
>>> plugin API, most of the Docker volume plugins are supported.
>>>
>>>
>>>
>>>
>>>
>>>   * [MESOS-4641] - **Experimental** A new network isolator, the
>>>
>>>
>>> `network/cni` isolator, has been introduced in the
>>> `MesosContainerizer`. The
>>>
>>> `network/cni` isolator implements the Container Network Interface
>>> (CNI)
>>>
>>> specification proposed by CoreOS.  With CNI the `network/cni`
>>> isolator is
>>>
>>> able to allocate a network namespace to Mesos containers and attach
>

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

[Kapil Arya]

+1 (binding)

OpenSUSE Tumbleweed:
./configure --disable-java --disable-python && make check

On Tue, Jul 26, 2016 at 4:44 PM, Zhitao Li <zhitaoli...@gmail.com> wrote:

> Also tested:
>
> make check passes on OS X
>
> One thing I found when testing RC4 debian with Aurora integration test
> suite (on its master) is that scheduler previously expected GPU resource
> will not receive offers without new `GPU_RESOURCES` capability even it's
> the only scheduler.
>
> Given that GPU support is not technically released until 1.0, I don't
> consider this is a blocker to me, but it might be surprising to people
> already testing GPU support.
>
> On Tue, Jul 26, 2016 at 12:45 PM, Benjamin Mahler <bmah...@apache.org>
> wrote:
>
>> +1 (binding)
>>
>> OS X 10.11.6
>> ./configure --disable-python --disable-java
>> make check
>>
>> On Tue, Jul 26, 2016 at 10:24 AM, Greg Mann <g...@mesosphere.io> wrote:
>>
>> > +1 (non-binding)
>> >
>> > * Ran `sudo make distcheck` successfully on CentOS 7.1 with only one
>> test
>> > failure: ExamplesTest.PythonFramework fails for me the first time it's
>> > executed as part of the whole test suite, and then succeeds on
>> subsequent
>> > executions. I'm investigating further, and will file a ticket if
>> necessary.
>> > * Ran the upgrade testing script successfully from 0.28.2 -> 1.0.0-rc4
>> >
>> > Cheers,
>> > Greg
>> >
>> > On Tue, Jul 26, 2016 at 1:58 AM, haosdent <haosd...@gmail.com> wrote:
>> >
>> >> +1
>> >>
>> >> * make check in CentOS 7.2
>> >> * make check in Ubuntu 14.04
>> >> * test upgrade from 0.28.2 to 1.0.0-rc4
>> >>
>> >>
>> >> On Tue, Jul 26, 2016 at 8:33 AM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >>
>> >> > One can find the deb/rpm packages here:
>> >> >
>> >> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4
>> >> >
>> >> > And here are the corresponding docker images based off of Ubuntu
>> 14.04:
>> >> > mesosphere/mesos:1.0.0-rc4
>> >> > mesosphere/mesos-master:1.0.0-rc4
>> >> > mesosphere/mesos-slave:1.0.0-rc4
>> >> >
>> >> > Kapil
>> >> >
>> >> > On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone <vinodk...@apache.org>
>> >> wrote:
>> >> >
>> >> > > Hi all,
>> >> > >
>> >> > >
>> >> > > Please vote on releasing the following candidate as Apache Mesos
>> >> 1.0.0.
>> >> > >
>> >> > > *The vote is open until Tue Jul 25 11:00:00 PDT 2016 and passes if
>> a
>> >> > > majority of at least 3 +1 PMC votes are cast.*
>> >> > >
>> >> > > 1.0.0 includes the following:
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> 
>> >> > >
>> >> > >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> >> APIs.
>> >> > > These
>> >> > >
>> >> > > APIs let operators and services (monitoring, load balancers)
>> send
>> >> > > HTTP
>> >> > >
>> >> > > requests to '/api/v1' endpoint on master or agent. See
>> >> > >
>> >> > >
>> >> > > `docs/operator-http-api.md` for details.
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> >> isolator
>> >> > >
>> >> > >
>> >> > > has been added to isolate disk resources more efficiently.
>> Please
>> >> > > refer to
>> >> > >
>> >> > > docs/mesos-containerizer.md for more details.
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>>

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

[Kapil Arya]

One can find the deb/rpm packages here:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc4

And here are the corresponding docker images based off of Ubuntu 14.04:
mesosphere/mesos:1.0.0-rc4
mesosphere/mesos-master:1.0.0-rc4
mesosphere/mesos-slave:1.0.0-rc4

Kapil

On Sat, Jul 23, 2016 at 1:40 AM, Vinod Kone  wrote:

> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>
> *The vote is open until Tue Jul 25 11:00:00 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.*
>
> 1.0.0 includes the following:
>
>
> 
>
>   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>
>
>
>
>
>   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> These
>
> APIs let operators and services (monitoring, load balancers) send
> HTTP
>
> requests to '/api/v1' endpoint on master or agent. See
>
>
> `docs/operator-http-api.md` for details.
>
>
>
>
>
>   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
>
>
> has been added to isolate disk resources more efficiently. Please
> refer to
>
> docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> added a
>
> new isolator 'docker/volume' which allows users to use external
> volumes in
>
> Mesos containerizer. Currently, the isolator interacts with the
> Docker
>
> volume plugins using a tool called 'dvdcli'. By speaking the Docker
> volume
>
> plugin API, most of the Docker volume plugins are supported.
>
>
>
>
>
>   * [MESOS-4641] - **Experimental** A new network isolator, the
>
>
> `network/cni` isolator, has been introduced in the
> `MesosContainerizer`. The
>
> `network/cni` isolator implements the Container Network Interface
> (CNI)
>
> specification proposed by CoreOS.  With CNI the `network/cni` isolator
> is
>
> able to allocate a network namespace to Mesos containers and attach
> the
>
> container to different types of IP networks by invoking network
> drivers
>
> called CNI plugins.
>
>
>
>
>
>   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> refactored in
>
> order to decouple the ACLs definition language from the interface.
>
>
> It additionally includes the option of retrieving `ObjectApprover`.
> An
>
> `ObjectApprover` can be used to synchronously check authorizations for
> a
>
> given object and is hence useful when authorizing a large number of
> objects
>
> and/or large objects (which need to be copied using request based
>
>
> authorization). NOTE: This is a **breaking change** for authorizer
> modules.
>
>
>
>
>   * [MESOS-5405] - The `subject` and `object` fields in
> authorization::Request
>
> have been changed from required to optional. If either of these fields
> is
>
> not set, the request should only be authorized if any subject/object
> should
>
> be allowed.
>
>
> NOTE: This is a semantic change for authorizer modules.
>
>
>
>
>
>   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> endpoint
>
> filtering enables operators to restrict what part of the cluster state
> a
>
> user is authorized to see.
>
>
> Consider for example the `/state` master endpoint: an operator can
> now
>
> authorize users to only see a subset of the running frameworks, tasks,
> or
>
> Consider for example the `/state` master endpoint: an operator can
> now
>
> authorize users to only see a subset of the running frameworks, tasks,
> or
>
> executors. The following endpoints support HTTP endpoint filtering:
>
>
> '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>
>
> and '/roles'. Additonally the following v1 API calls support
> filtering:
>
> 'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> 'GET_TASKS'.
>
>
>
>
>   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> best-effort,
>
> because machine failures or forcible terminations may occur.
> Currently, the
>
> only available kill policy is how long to wait between graceful and
> forcible
>
> task kill. In the future, more policies may be available (e.g. hitting
> an
>
> HTTP endpoint, running a command, etc). Note that it is the
> executor's
>
> responsibility to enforce kill policies. For executor-less
> command-based
>
> tasks, the kill is performed via sending a signal to the task
> process:
>
> SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> docker
>
> executor-less tasks the grace period is passed to 'docker stop
> --time'. This
>
> feature supersedes the '--docker_stop_timeout', which is now
> deprecated.
>
>
>
>
>   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> be
>
> overridden when the scheduler 

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

[Kapil Arya]

None of the stable builds have SSL yet. The first SSL-enabled stable build
will be 1.0.0. Sorry for the confusion.

Kapil

On Mon, Jul 11, 2016 at 1:03 PM, Zhitao Li <zhitaoli...@gmail.com> wrote:

> Hi Kapil,
>
> Do you mean that the stable builds from
> http://open.mesosphere.com/downloads/mesos is using the new configuration?
>
> On Sun, Jul 10, 2016 at 10:07 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> The binary rpm/deb packages can be found here:
>> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2
>> .
>>
>> Please note that starting with the 1.0.0 release (including RCs and
>> recent nightly builds), Mesos is configured with SSL and 3rdparty
>> module dependency installation. Here is the configure command line:
>> ./configure --enable-libevent --enable-ssl
>> --enable-install-module-dependencies
>>
>> As always, the stable builds are available at:
>> http://open.mesosphere.com/downloads/mesos
>>
>> The instructions for nightly builds are available at:
>> http://open.mesosphere.com/downloads/mesos-nightly/
>>
>> Best,
>> Kapil
>>
>>
>> On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone <vinodk...@apache.org> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>> >
>> >
>> > 1.0.0 includes the following:
>> >
>> >
>> 
>> >
>> >   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4791] - **Experimental** support for v1 Master and Agent
>> APIs.
>> > These
>> >
>> > APIs let operators and services (monitoring, load balancers) send
>> HTTP
>> >
>> >
>> > requests to '/api/v1' endpoint on master or agent. See
>> >
>> >
>> > `docs/operator-http-api.md` for details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4828] - **Experimental** support for a new `disk/xfs'
>> isolator
>> >
>> >
>> > has been added to isolate disk resources more efficiently. Please
>> refer
>> > to
>> >
>> > docs/mesos-containerizer.md for more details.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
>> > added a
>> >
>> > new isolator 'docker/volume' which allows users to use external
>> volumes
>> > in
>> >
>> > Mesos containerizer. Currently, the isolator interacts with the
>> Docker
>> >
>> >
>> > volume plugins using a tool called 'dvdcli'. By speaking the Docker
>> > volume
>> >
>> > plugin API, most of the Docker volume plugins are supported.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-4641] - **Experimental** A new network isolator, the
>> >
>> >
>> > `network/cni` isolator, has been introduced in the
>> > `MesosContainerizer`. The
>> >
>> > `network/cni` isolator implements the Container Network Interface
>> (CNI)
>> >
>> >
>> > specification proposed by CoreOS.  With CNI the `network/cni`
>> isolator
>> > is
>> >
>> > able to allocate a network namespace to Mesos containers and attach
>> the
>> >
>> >
>> > container to different types of IP networks by invoking network
>> drivers
>> >
>> >
>> > called CNI plugins.
>> >
>> >
>> >
>> >
>> >
>> >   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
>> refactored
>> > in
>> >
>> > order to decouple the ACLs definition language from the interface.
>> >
>> >
>> > It additionally includes the option of retrieving `ObjectApprover`.
>> An
>> >
>> >
>> > `ObjectApprover` can be used to synchronously check authorizations
>> for
>> > a
>> >
>> > given object and is hence useful when authorizing a large number of
>> > objects
>> >
>> > and/or large objects (which need to be copied using request based
>> >
>> >
>> > authorization). NOTE: This 

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

[Kapil Arya]

The binary rpm/deb packages can be found here:
http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc2.

Please note that starting with the 1.0.0 release (including RCs and
recent nightly builds), Mesos is configured with SSL and 3rdparty
module dependency installation. Here is the configure command line:
./configure --enable-libevent --enable-ssl
--enable-install-module-dependencies

As always, the stable builds are available at:
http://open.mesosphere.com/downloads/mesos

The instructions for nightly builds are available at:
http://open.mesosphere.com/downloads/mesos-nightly/

Best,
Kapil

On Thu, Jul 7, 2016 at 9:35 PM, Vinod Kone  wrote:
>
> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
>
>
> 1.0.0 includes the following:
>
>

>
>   * Scheduler and Executor v1 HTTP APIs are now considered stable.
>
>
>
>
>
>   * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> These
>
> APIs let operators and services (monitoring, load balancers) send HTTP
>
>
> requests to '/api/v1' endpoint on master or agent. See
>
>
> `docs/operator-http-api.md` for details.
>
>
>
>
>
>   * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
>
>
> has been added to isolate disk resources more efficiently. Please
refer
> to
>
> docs/mesos-containerizer.md for more details.
>
>
>
>
>
>   * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> added a
>
> new isolator 'docker/volume' which allows users to use external
volumes
> in
>
> Mesos containerizer. Currently, the isolator interacts with the Docker
>
>
> volume plugins using a tool called 'dvdcli'. By speaking the Docker
> volume
>
> plugin API, most of the Docker volume plugins are supported.
>
>
>
>
>
>   * [MESOS-4641] - **Experimental** A new network isolator, the
>
>
> `network/cni` isolator, has been introduced in the
> `MesosContainerizer`. The
>
> `network/cni` isolator implements the Container Network Interface
(CNI)
>
>
> specification proposed by CoreOS.  With CNI the `network/cni` isolator
> is
>
> able to allocate a network namespace to Mesos containers and attach
the
>
>
> container to different types of IP networks by invoking network
drivers
>
>
> called CNI plugins.
>
>
>
>
>
>   * [MESOS-2948, MESOS-5403] - The authorizer interface has been
refactored
> in
>
> order to decouple the ACLs definition language from the interface.
>
>
> It additionally includes the option of retrieving `ObjectApprover`. An
>
>
> `ObjectApprover` can be used to synchronously check authorizations for
> a
>
> given object and is hence useful when authorizing a large number of
> objects
>
> and/or large objects (which need to be copied using request based
>
>
> authorization). NOTE: This is a **breaking change** for authorizer
> modules.
>
>
>
>
>   * [MESOS-5405] - The `subject` and `object` fields in
> authorization::Request
>
> have been changed from required to optional. If either of these fields
> is
>
> not set, the request should only be authorized if any subject/object
> should
>
> be allowed.
>
> NOTE: This is a semantic change for authorizer modules.
>
>
>
>
>
>   * [MESOS-4931, MESOS-5709, MESOS-5704] - Authorization based HTTP
> endpoint
>
> filtering enables operators to restrict what part of the cluster state
> a
>
> user is authorized to see.
>
>
> Consider for example the `/state` master endpoint: an operator can now
>
>
> authorize users to only see a subset of the running frameworks, tasks,
> or
>
> executors. The following endpoints support HTTP endpoint filtering:
>
>
> '/state', '/state-summary', '/tasks', '/frameworks','/weights',
>
>
> and '/roles'. Additonally the following v1 API calls support
filtering:
>
>
> 'GET_ROLES','GET_WEIGHTS','GET_FRAMEWORKS', 'GET_STATE', and
> 'GET_TASKS'.
>
>
>
>
>   * [MESOS-4909] - Tasks can now specify a kill policy. They are
> best-effort,
>
> because machine failures or forcible terminations may occur.
Currently,
> the
>
> only available kill policy is how long to wait between graceful and
> forcible
>
> task kill. In the future, more policies may be available (e.g. hitting
> an
>
> HTTP endpoint, running a command, etc). Note that it is the executor's
>
>
> responsibility to enforce kill policies. For executor-less
> command-based
>
> tasks, the kill is performed via sending a signal to the task process:
>
>
> SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> docker
>
> executor-less tasks the grace period is passed to 'docker stop
--time'.
> This
>
> feature supersedes the '--docker_stop_timeout', which is now
> deprecated.
>
>
>
>
>   * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> be
>

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

[Kapil Arya]

+1 (binding) Internal CI build.

Here is a link to the deb/rpm packages:

http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-0.26.2-rc1



On Mon, Jun 20, 2016 at 6:07 PM, Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI w/ ubuntu. Note that centos:7 build issue is due to a
> known configuration issue (unable to find JAVA_HOME), fixed in 0.27.0, with
> the build script.
>
> *Revision*: 5edc7bab79649341c44df21c8842e05fb6d6c2bb
>
>- refs/tags/0.26.2-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl
> [image: Failed]
> 
> [image: Not run]
> --verbose
> [image: Failed]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl
> [image: Success]
> 
> [image: Success]
> 
> --verbose
> [image: Success]
> 
> [image: Success]
> 
>
> On Mon, Jun 20, 2016 at 11:25 AM, Jie Yu  wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 0.26.2.
>>
>>
>> 0.26.2 is a bug fix release. It includes the following:
>>
>> 
>> [MESOS-4705] - Linux 'perf' parsing logic may fail when OS distribution
>> has perf backports.
>> [MESOS-5449] - Memory leak in SchedulerProcess.declineOffer.
>>
>> The CHANGELOG for the release is available at:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.26.2-rc1
>>
>> 
>>
>> The candidate for Mesos 0.26.2 release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.2-rc1/mesos-0.26.2.tar.gz
>>
>> The tag to be voted on is 0.26.2-rc1:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.26.2-rc1
>>
>> The MD5 checksum of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.2-rc1/mesos-0.26.2.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.26.2-rc1/mesos-0.26.2.tar.gz.asc
>>
>> The PGP key used to sign the release is here:
>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>
>> The JAR is up in Maven in a staging repository here:
>> https://repository.apache.org/content/repositories/orgapachemesos-1147
>>
>> Please vote on releasing this package as Apache Mesos 0.26.2!
>>
>> The vote is open until Thu Jun 23 11:23:33 PDT 2016 and passes if a
>> majority of at least 3 +1 PMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Mesos 0.26.2
>> [ ] -1 Do not release this package because ...
>>
>> Thanks
>> - Jie
>>
>
>

Re: Slack as the canonical chat channel

[Kapil Arya]

+1 Slack!

On Fri, Jun 17, 2016 at 4:37 PM, Yan Xu  wrote:

> +1 Slack.
>
> On Friday, June 17, 2016, José Guilherme Vanz 
> wrote:
>
> > +1 Slack
> >
> > On Fri, 17 Jun 2016 at 17:05 Joris Van Remoortere 
> > wrote:
> >
> > > +1 Slack
> > >
> > > —
> > > *Joris Van Remoortere*
> > > Mesosphere
> > >
> > > On Fri, Jun 17, 2016 at 10:04 PM, Vinod Kone 
> > wrote:
> > >
> > > > Looks like people have jumped the gun here before I sent the email :)
> > > >
> > > > Here is the context. During the community sync we discussed about
> using
> > > > *Slack* or *HipChat* as our official chat channel instead of our
> > current
> > > > #mesos IRC channel on freenode.
> > > >
> > > > The main reasons for using Slack/Hipchat are
> > > >
> > > >- In-client chat history
> > > >- Discoverability of work group specific channels
> > > >- Email notifications when offline
> > > >- Modern UX and clients
> > > >
> > > > During the sync most people preferred the move to *Slack*. I wanted
> to
> > > get
> > > > a sense from other community members as well through this email.
> Please
> > > let
> > > > us know what you think.
> > > >
> > > > Note that even if we move to Slack, we will make sure people can
> still
> > > > connect using IRC clients and that the chat history is publicly
> > available
> > > > (per ASF guidelines). During the transition period, we might mirror
> > > > messages from Slack channel to IRC and vice-versa.
> > > >
> > > > Thoughts?
> > > >
> > > > On Fri, Jun 17, 2016 at 8:52 AM, Vinit Mahedia <
> vinitmahe...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > +1 Slack.
> > > > >
> > > > > On Fri, Jun 17, 2016 at 12:59 AM, Jay JN Guo <
> guojian...@cn.ibm.com>
> > > > > wrote:
> > > > >
> > > > > > +1 Slack!
> > > > > >
> > > > > > /J
> > > > > >
> > > > > > Vaibhav Khanduja  wrote on 06/16/2016
> > > > > 22:26:27:
> > > > > >
> > > > > > > From: Vaibhav Khanduja 
> > > > > > > To: dev@mesos.apache.org
> > > > > > > Date: 06/16/2016 22:26
> > > > > > > Subject: Re: Notification: Community Meeting @ Thu Jun 16, 2016
> > 3pm
> > > > > > > - 4pm (Apache Mesos)
> > > > > > >
> > > > > > > + 1 slack
> > > > > > >
> > > > > > > Sent from my iPhone. Please excuse for typos and brevity of
> this
> > > > > message.
> > > > > > >
> > > > > > > > On Jun 16, 2016, at 6:46 PM, haosdent 
> > > wrote:
> > > > > > > >
> > > > > > > > +1 For Slack.
> > > > > > > >
> > > > > > > >> On Fri, Jun 17, 2016 at 7:33 AM, Greg Mann <
> > g...@mesosphere.io>
> > > > > > wrote:
> > > > > > > >>
> > > > > > > >> Hello all,
> > > > > > > >> Here are the notes from our community sync meeting this
> > > afternoon:
> > > > > > > >>
> > > > > > > >> Attendees:
> > > > > > > >>
> > > > > > > >> Mesosphere: Joris, Greg, Haris, Artem, Joseph, Kapil, Anand,
> > > > > Gilbert,
> > > > > > > >> Harpreet, Kevin, Vinod, Jie, Joerg, MPark
> > > > > > > >>
> > > > > > > >> Uber: Zhitao Li
> > > > > > > >>
> > > > > > > >> Agenda/Note:
> > > > > > > >>
> > > > > > > >>   -
> > > > > > > >>
> > > > > > > >>   Reviewing the list of maintainers on
> > > > > > > >>   http://mesos.apache.org/documentation/latest/committers/
> > > > > > > >>   -
> > > > > > > >>
> > > > > > > >>  Add components for
> > > > > > > >>  -
> > > > > > > >>
> > > > > > > >> Documentation (docs/*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Windows (*windows*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> C++ standards (docs/c++-style-guide.md)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> HTTP API (http.*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Persistence
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Test infrastructure (src/tests/*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Build-related
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >>Autotools, CMake
> > > > > > > >>-
> > > > > > > >>
> > > > > > > >> Subdivide Stout
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Subdivide Libprocess (3rdparty/libprocess/*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Subdivide Container-related things
> > > > > (src/slave/containerizer/*)
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >>Networking
> > > > > > > >>-
> > > > > > > >>
> > > > > > > >>Storage
> > > > > > > >>-
> > > > > > > >>
> > > > > > > >> Resource allocation/Scheduler
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >> Development tools
> > > > > > > >> -
> > > > > > > >>
> > > > > > > >>  Think about some tooling to facilitate this
> > > > > > > >>  -
> > > > > > > >>
> > > > > > > >> 

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

[Kapil Arya]

Here is a link to the rpm/deb packages for Mesos 1.0.0-rc1:

http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.0.0-rc1

Please note that from this release (>=1.0.0-rc1) onwards, we are
configuring Mesos with SSL support. We have also added
`--enable-install-module-dependencies` configure flag to help ease module
development.

Finally, we'll continue to build the older bugfix releases for Mesos
versions <1.0.0 _without_ SSL support.

Best,
Kapil

On Tue, Jun 7, 2016 at 5:45 AM, Jörg Schad  wrote:

> Hi,
> the authorization documentation in the RC seems to be messing some changes
> introduced by https://issues.apache.org/jira/browse/MESOS-5405.
> We already added and committed fixes as part this ticket (see
>
> https://issues.apache.org/jira/browse/MESOS-5405?focusedCommentId=15318058=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15318058
> )
> but they should be included in the next RC (given that there will be a rc2
> :-) ).
>
> On Tue, Jun 7, 2016 at 3:32 AM, Robert Lacroix  wrote:
>
> > Hi Vinod,
> >
> > In convert.cpp
> > <
> https://github.com/apache/mesos/blob/master/src/java/jni/convert.cpp#L153>
> we
> > compare the major versions of the native library and the jar. This makes
> > upgrading frameworks unnecessarily hard because you would have to deploy
> > Mesos and frameworks in lockstep.
> >
> > Non-binding -1 , as this check isn’t strictly useful - especially given
> > this is probably the last major upgrade where libmesos is even relevant.
> >
> >  Robert
> >
> > On Jun 1, 2016, at 12:38 AM, Vinod Kone  wrote:
> >
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.0.0.
> >
> >
> > NOTE: The voting period for this release is 3 weeks. Also, we are willing
> > to make API changes before the final release. So please test it
> thoroughly.
> >
> >
> > 1.0.0 includes the following features:
> >
> >
> >
> 
> >
> >  * Scheduler and Executor v1 HTTP APIs are now considered stable.
> >
> >
> >
> >
> >
> >  * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> > These
> >
> >APIs let operators and services (monitoring, load balancers) send HTTP
> >
> >
> >requests to '/api/v1' endpoint on master or agent. These APIs look
> > similar
> >
> >to the v1 Scheduler and Executor APIs.
> >
> >
> >
> >
> >
> >  * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
> >
> >
> >has been added to isolate disk resources more efficiently. Please
> refer
> > to
> >
> >docs/mesos-containerizer.md for more details.
> >
> >
> >
> >
> >
> >  * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> > added a
> >
> >new isolator 'docker/volume' which allows users to use external
> volumes
> > in
> >
> >Mesos containerizer. Currently, the isolator interacts with the Docker
> >
> >
> >volume plugins using a tool called 'dvdcli'. By speaking the Docker
> > volume
> >
> >plugin API, most of the Docker volume plugins are supported.
> >
> >
> >
> >
> >
> >  * [MESOS-4641] - **Experimental** A new network isolator, the
> >
> >
> >`network/cni` isolator, has been introduced in the
> > `MesosContainerizer`. The
> >
> >`network/cni` isolator implements the Container Network Interface
> (CNI)
> >
> >
> >specification proposed by CoreOS.  With CNI the `network/cni` isolator
> > is
> >
> >able to allocate a network namespace to Mesos containers and attach
> the
> >
> >
> >container to different types of IP networks by invoking network
> drivers
> >
> >
> >called CNI plugins.
> >
> >
> >
> >
> >
> >  * [MESOS-2948, MESOS-5403] - The authorizer interface has been
> refactored
> > in
> >
> >order to decouple the ACLs definition language from the interface.
> >
> >
> >It additionally includes the option of retrieving `ObjectApprover`. An
> >
> >
> >`ObjectApprover` can be used to synchronously check authorizations for
> > a
> >
> >given object and is hence useful when authorizing a large number of
> > objects
> >
> >and/or large objects (which need to be copied using request based
> >
> >
> >authorization). NOTE: This is a **breaking change** for authorizer
> > modules.
> >
> >
> >
> >
> >  * [MESOS-4931] - Authorization based HTTP endpoint filtering enables
> > operators
> >
> >to restrict what part of the cluster state a user is authorized to
> see.
> >
> >
> >Consider for example the `/state` master endpoint: an operator can now
> >
> >
> >authorize users to only see a subset of the running frameworks, tasks,
> > or
> >
> >executors.
> >
> >
> >
> >
> >
> >  * [MESOS-4909] - Tasks can now specify a kill policy. They are
> > best-effort,
> >
> >because machine failures or forcible terminations may occur.
> Currently,
> > the
> >
> >only available kill policy is how 

Re: 0.28.2 has been released

[Kapil Arya]

Hi All,

The 0.28.2 rpm/deb packages can be found here:
http://open.mesosphere.com/downloads/mesos/#apache-mesos-0.28.2

Best,
Kapil

On Mon, Jun 6, 2016 at 5:21 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> Hi Craig,
>
> I should be sending out a link to the RPM packages in a couple of days.
> (Our packaging scripts had some issues and I am working on fixing them).
>
> Kapil
>
> On Mon, Jun 6, 2016 at 6:15 AM, craig w <codecr...@gmail.com> wrote:
>
>> Jie,
>>
>> Thanks for the updates. When will the packages be available (in
>> particular RPM)?
>>
>> -craig
>>
>> On Sun, Jun 5, 2016 at 2:31 PM, Jie Yu <yujie@gmail.com> wrote:
>>
>>> Hi folks,
>>>
>>> I just released Mesos 0.28.2 and updated the website.
>>>
>>> It includes some important bug fixes. The change log can be found here:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.2
>>>
>>> If you are considering using 0.28, please use 0.28.2!
>>>
>>> Thanks!
>>> - Jie
>>>
>>
>>
>>
>> --
>>
>> https://github.com/mindscratch
>> https://www.google.com/+CraigWickesser
>> https://twitter.com/mind_scratch
>> https://twitter.com/craig_links
>>
>>
>

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

[Kapil Arya]

+1 (binding) Ran CI builds for various distros.

The deb/rpm packages can be found here:

http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-0.27.3-rc1

Kapil

On Tue, Jun 7, 2016 at 1:42 PM, Jie Yu  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.27.3.
>
> NOTE: I fat fingered and accidentally released the 0.27.3 jar to maven repo
> and I have no permission to remove it (apologies!). If this vote passes,
> nothing needs to be done. If not, I'll see how I can update it. Sorry about
> that.
>
>
> 0.27.3 is a bug fix release. It includes the following fixes:
>
> 
> ** Bug
>   * [MESOS-4705] - Linux 'perf' parsing logic may fail when OS distribution
> has perf backports.
>   * [MESOS-4869] - /usr/libexec/mesos/mesos-health-check using/leaking a
> lot of memory.
>   * [MESOS-5018] - FrameworkInfo Capability enum does not support upgrades.
>   * [MESOS-5021] - Memory leak in subprocess when 'environment' argument is
> provided.
>   * [MESOS-5449] - Memory leak in SchedulerProcess.declineOffer.
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.3-rc1
>
> 
>
> The candidate for Mesos 0.27.3 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.3-rc1/mesos-0.27.3.tar.gz
>
> The tag to be voted on is 0.27.3-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.3-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.3-rc1/mesos-0.27.3.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.3-rc1/mesos-0.27.3.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1145
>
> Please vote on releasing this package as Apache Mesos 0.27.3!
>
> The vote is open until Fri Jun 10 10:38:44 PDT 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.27.3
> [ ] -1 Do not release this package because ...
>
> Thanks,
> - Jie
>

Re: 0.28.2 has been released

[Kapil Arya]

Hi Craig,

I should be sending out a link to the RPM packages in a couple of days.
(Our packaging scripts had some issues and I am working on fixing them).

Kapil

On Mon, Jun 6, 2016 at 6:15 AM, craig w  wrote:

> Jie,
>
> Thanks for the updates. When will the packages be available (in particular
> RPM)?
>
> -craig
>
> On Sun, Jun 5, 2016 at 2:31 PM, Jie Yu  wrote:
>
>> Hi folks,
>>
>> I just released Mesos 0.28.2 and updated the website.
>>
>> It includes some important bug fixes. The change log can be found here:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.2
>>
>> If you are considering using 0.28, please use 0.28.2!
>>
>> Thanks!
>> - Jie
>>
>
>
>
> --
>
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links
>
>

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

[Kapil Arya]

+1 (binding)

Distro package building for Ubuntu, Debian and CentOS. Here is the link to
the RC downloads page:
  http://open.mesosphere.com/downloads/mesos-rc/

Best,
Kapil



On Mon, May 30, 2016 at 3:17 PM, Till Toenshoff  wrote:

> +1
>
> Tested on OSX and various distros via private CI.
>
> OSX 10.11.5 (15F34), clang version 3.7.0 (trunk 235831) (llvm/trunk
> 235813):
>
> 
> [--] Global test environment tear-down
> [==] 1009 tests from 132 test cases ran. (299208 ms total)
> [  PASSED  ] 1003 tests.
> [  FAILED  ] 6 tests, listed below:
> [  FAILED  ] ExamplesTest.TestFramework
> [  FAILED  ] ExamplesTest.NoExecutorFramework
> [  FAILED  ] ExamplesTest.JavaFramework
> [  FAILED  ] ExamplesTest.PythonFramework
> [  FAILED  ] FetcherCacheTest.LocalUncachedExtract
> [  FAILED  ] FetcherCacheHttpTest.HttpMixed
>
>
> Debian 8
>
> ---
> [19:05:20][Step 10/10] [  PASSED  ] 1126 tests.
>
> Debian 8 - SSL
>
> ---
> [19:03:47][Step 10/10] [  PASSED  ] 1126 tests.
>
>
> Ubuntu 12
>
> ---
> [19:00:36][Step 10/10] [  PASSED  ] 1127 tests.
>
> Ubuntu 12 - SSL
>
> ---
> [19:01:53][Step 10/10] [  PASSED  ] 1127 tests.
>
> Ubuntu 14
>
> ---
> [19:01:19][Step 10/10] [  PASSED  ] 1125 tests.
>
> Ubuntu 14 - SSL
>
> ---
> [19:00:20][Step 10/10] [  PASSED  ] 1125 tests.
>
> Ubuntu 15
>
> ---
> [19:05:28][Step 10/10] [  PASSED  ] 1128 tests.
>
> Ubuntu 15 - SSL
>
> ---
> [19:05:58][Step 10/10] [  PASSED  ] 1128 tests.
>
>
> Centos 6
>
> ---
> [19:07:27][Step 10/10] [  PASSED  ] 1127 tests.
> [19:07:27][Step 10/10] [  FAILED  ] 1 test, listed below:
> [19:07:27][Step 10/10] [  FAILED  ]
> MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>
> Centos 6 - SSL
>
> ---
> [19:07:29][Step 10/10] [  PASSED  ] 1127 tests.
> [19:07:29][Step 10/10] [  FAILED  ] 1 test, listed below:
> [19:07:29][Step 10/10] [  FAILED  ]
> MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
>
> Centos 7
>
> ---
> [19:05:43][Step 10/10] [  PASSED  ] 1129 tests.
> [19:05:43][Step 10/10] [  FAILED  ] 1 test, listed below:
> [19:05:43][Step 10/10] [  FAILED  ]
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
>
> Centos 7 - SSL
>
> ---
> [19:04:53][Step 10/10] [  PASSED  ] 1129 tests.
> [19:04:53][Step 10/10] [  FAILED  ] 1 test, listed below:
> [19:04:53][Step 10/10] [  FAILED  ]
> LinuxFilesystemIsolatorTest.ROOT_MultipleContainers
>
>
>
>
>
> On May 30, 2016, at 8:23 AM, Vinod Kone  wrote:
>
> +1 (binding)
>
> Tested on ASF CI
>
> *Revision*: ceecad69bd9656cf405ca7378ad021c4ad51aaed
>
>   - refs/tags/0.28.2-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl
> [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/15/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image: Not run]
> --verbose
> [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/15/COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl
> [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/15/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image: Success]
> <
> 

Re: Reorganize 3rdparty directory

[Kapil Arya]

ng term, but avoiding them
> >> >> in the short term.  We should get things organized as we want them
> >> >> first, and then start thinking about pulling libprocess/stout out
> into
> >> >> submodules later (while also preserving their history!)
> >> >>
> >> >> I disagree with moving libprocess and stout up to the same level as
> >> >> src/. If we want to make sure they don't bleed into Mesos proper, we
> >> >> really should treat them the same as any other 3rdparty code that we
> >> >> depend on.  This will become more relevant when/if we move them into
> >> >> submodules.
> >> >>
> >> >> Given all that, the only real challenge with flattening our 3rdparty
> >> >> dependencies into a single folder should be the changes we have to
> >> >> make to our configure.ac and Makefile.am scripts to know where to
> look
> >> >> for their dependencies now.  In the end these should be URLs to
> >> >> versioned tarballs that we host somewhere (or git repos that we can
> >> >> have forked and tagged with specific versions).  In the short term
> >> >> these can just be relative paths in the mesos tree though.
> >> >>
> >> >> On Tue, Feb 16, 2016 at 1:26 PM, Kapil Arya <ka...@mesosphere.io>
> >> wrote:
> >> >>> Thanks for bringing it up Alexander!
> >> >>>
> >> >>> I don't have a strong opinion wrt git submodules since I don't have
> >> >>> much experience with them personally. Having said that, I would like
> >> >>> to go conservative on this one (baby steps :-) ).
> >> >>>
> >> >>> Further, I do understand that moving libprocess and stout
> directories
> >> >>> will be painful for people who already have several branches and
> will
> >> >>> have conflicts. But I do think, there are some interim solutions as
> >> >>> well (for example, move libprocess/stout to wherever we want, but
> keep
> >> >>> a symlink from 3rdparty/libprocess, etc, to those new locations for
> >> >>> some time). I am sure there are better solutions out there, but this
> >> >>> should work too.
> >> >>>
> >> >>> Best,
> >> >>> Kapil
> >> >>>
> >> >>> On Tue, Feb 16, 2016 at 12:38 PM, Erik Weathers
> >> >>> <eweath...@groupon.com.invalid> wrote:
> >> >>>> If we go to git submodules, please ensure there are good docs
> around
> >> how to
> >> >>>> update cloned repos.
> >> >>>>
> >> >>>> e.g., From ansible:
> >> https://docs.ansible.com/ansible/intro_installation.html
> >> >>>>
> >> >>>> Note when updating ansible, be sure to not only update the source
> >> tree, but
> >> >>>> also the “submodules” in git which point at Ansible’s own modules
> >> (not the
> >> >>>> same kind of modules, alas).
> >> >>>>
> >> >>>> $ git pull --rebase
> >> >>>> $ git submodule update --init --recursive
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> - Erik
> >> >>>>
> >> >>>> On Tue, Feb 16, 2016 at 8:54 AM, Alexander Rojas <
> >> alexan...@mesosphere.io>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> +1
> >> >>>>> I am one who is totally in for that change. It is not only the
> >> directories
> >> >>>>> problem, but the structure which has led that the stout tests
> (which
> >> do
> >> >>>>> need to be compiled) are actually managed in the libprocess
> >> Makefile, on
> >> >>>>> top of all the things you have already mentioned.
> >> >>>>>
> >> >>>>>
> >> >>>>> > On 09 Feb 2016, at 17:53, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >> >>>>> >
> >> >>>>> > On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu <yujie@gmail.com>
> >> wrote:
> >> >>>>> >> Kapil,
> >> >>>>> >>
> >> >>>>> >> I guess what I want to u

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

[Kapil Arya]

+1 (binding)

CI runs with: amd64/centos/6 amd64/centos/7 amd64/debian/jessie
amd64/ubuntu/precise amd64/ubuntu/trusty amd64/ubuntu/vivid
amd64/ubuntu/wily

On Wed, Apr 6, 2016 at 11:51 PM, Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI. There was one flaky test that's new:
> https://issues.apache.org/jira/browse/MESOS-5139
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Not run]
> --verbose [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Failed]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=clang,CONFIGURATION=--verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> --verbose [image: Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
> [image:
> Success]
> <
> https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/13/COMPILER=clang,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/
> >
>
> On Wed, Apr 6, 2016 at 7:34 PM, Michael Park  wrote:
>
> > +1 (binding)
> >
> > Internal CI results with the corresponding JIRA tickets for the failed
> > tests:
> >
> > CentOS 6 (non-SSL):
> > CentOS 6 (SSL):
> >   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> > (MESOS-4047 ,
> > MESOS-4053 )
> >
> > CentOS 7 (non-SSL):
> >   - HealthCheckTest.ROOT_DOCKER_DockerHealthyTask
> > (MESOS-4604 )
> >
> > CentOS 7 (SSL):
> >   -
> >
> >
> LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystemCommandExecutorWithVolumes
> > (Segfault during test teardown, likely addressed in 0.29.0 by
> > MESOS-4633
> >  and MESOS-4634
> > )
> >
> > Debian 8 (non-SSL):
> > Debian 8 (SSL):
> >   - HealthCheckTest.ROOT_DOCKER_DockerHealthyTask
> > (MESOS-4604 )
> >
> > Ubuntu 12 (non-SSL): Success!
> > Ubuntu 12 (SSL):Success!
> > Ubuntu 14 (non-SSL): Success!
> > Ubuntu 14 (SSL):Success!
> > Ubuntu 15 (non-SSL): Success!
> > Ubuntu 15 (SSL):Success!
> >
> > On 5 April 2016 at 22:30, Greg Mann  wrote:
> >
> > > +1 (non-binding)
> > >
> > > Ran `sudo make check` on CentOS 7 with libevent and SSL enabled; all
> > tests
> > > pass.
> > >
> > > I was also able to successfully simulate a simple upgrade scenario
> using
> > > 'test-upgrade.py'. Note that this initially failed due to some changes
> > made
> > > to the test framework in this release, but after applying this patch
> > >  the upgrade script succeeds.
> While
> > > ideally this patch for the upgrade script would be included in the
> > release,
> > > I don't consider it to be a blocker. If we end up cutting another RC,
> it
> > > would be great to include.
> > >
> > > Cheers,
> > > Greg
> > >
> > >
> > > On Tue, Apr 5, 2016 at 6:30 PM, Jie Yu  wrote:
> > >
> > > > Hi all,
> > > >
> > > > Please vote on releasing the following candidate as Apache Mesos
> > 0.28.1.
> > > >
> > > >
> > > > 0.28.1 includes the following bug fixes:
> > > >
> > > >
> > >
> >
> 
> > > >
> > > > [MESOS-4662] - PortMapping network isolator should not assume
> > > > BIND_MOUNT_ROOT is a realpath.
> > > > [MESOS-4874] - overlayfs does not work with kernel 4.2.3
> > > > [MESOS-4877] - Mesos containerizer can't handle top level docker
> image
> > > > like "alpine" (must use "library/alpine")
> > > > [MESOS-4878] - Task stuck in TASK_STAGING when docker fetcher failed
> to
> > > > fetch the image
> > > > [MESOS-4964] - curl based docker fetcher 

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

[Kapil Arya]

+1 (binding)

CI runs with: amd64/centos/6 amd64/centos/7 amd64/debian/jessie
amd64/ubuntu/precise amd64/ubuntu/trusty amd64/ubuntu/vivid
amd64/ubuntu/wily

On Wed, Apr 6, 2016 at 11:53 PM, Vinod Kone  wrote:

> +1(binding)
>
> Tested on ASF CI.
>
> The centos failures are due to a known bug in the docker build script that
> cannot guess JAVA_HOME (has been fixed since).
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl
> [image: Failed]
> 
> [image: Not run]
> --verbose
> [image: Failed]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl
> [image: Success]
> 
> [image: Success]
> 
> --verbose
> [image: Success]
> 
> [image: Success]
> 
>
> On Wed, Apr 6, 2016 at 8:50 PM, Vinod Kone  wrote:
>
>> oops wrong email thread. this should be for 28.1 voting thread.
>>
>> canceling this particular vote. i'll vote for 26.1 shortly.
>>
>> On Wed, Apr 6, 2016 at 8:46 PM, Vinod Kone  wrote:
>>
>>> +1 (binding)
>>>
>>> Tested on ASF CI. There was one flaky test that's new:
>>> https://issues.apache.org/jira/browse/MESOS-5139
>>>
>>> Configuration Matrix gcc clang
>>> centos:7 --verbose --enable-libevent --enable-ssl
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> --verbose
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> ubuntu:14.04 --verbose --enable-libevent --enable-ssl
>>> [image: Success]
>>> 
>>> [image: Failed]
>>> 
>>> --verbose
>>> [image: Success]
>>> 
>>> [image: Success]
>>> 
>>>
>>> On Wed, Apr 6, 2016 at 6:17 PM, Benjamin Mahler 
>>> wrote:
>>>
 +1 (binding)

 The following passes on OS X:
 $ ./configure CC=clang CXX=clang++ --disable-python --disable-java
 $ make check

 On Tue, Apr 5, 2016 at 11:41 PM, Michael Park  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos
> 0.26.1.
>
>
> 0.26.1 includes the following:
>
> 
> No changes from rc3:
>
> * Improvements
>   - `/state` endpoint performance
>   - `systemd` integration
>   - GLOG performance
>   - Configurable 

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

[Kapil Arya]

+1 (binding)

CI runs for amd64/centos/6 amd64/centos/7 amd64/debian/jessie
amd64/ubuntu/precise amd64/ubuntu/trusty amd64/ubuntu/vivid amd64/


On Wed, Apr 6, 2016 at 9:43 PM, Vinod Kone  wrote:

> +1 (binding)
>
> `./configure && make check` on ubuntu 14.04
>
> On Wed, Apr 6, 2016 at 6:18 PM, Benjamin Mahler 
> wrote:
>
>> +1 (binding)
>>
>> The following passes on OS X:
>> $ ./configure CC=clang CXX=clang++ --disable-python --disable-java
>> $ make check
>>
>> On Tue, Apr 5, 2016 at 11:41 PM, Michael Park  wrote:
>>
>> > s/No changes from rc4/No changes from rc3/
>> > s/New fixes in rc5/New fixes in rc4/
>> >
>> > On 5 April 2016 at 23:18, Michael Park  wrote:
>> >
>> >> Hi all,
>> >>
>> >> Please vote on releasing the following candidate as Apache Mesos
>> 0.25.1.
>> >>
>> >>
>> >> 0.25.1 includes the following:
>> >>
>> >>
>> 
>> >> No changes from rc4:
>> >>
>> >> * Improvements
>> >>   - `/state` endpoint performance
>> >>   - `systemd` integration
>> >>   - GLOG performance
>> >>   - Configurable task/framework history
>> >>   - Offer filter timeout fix for backlogged allocator
>> >>   - JSON-based credential files. (MESOS-3560)
>> >>   - Mesos health check within docker container. (MESOS-3738)
>> >>   - Deletion of special files. (MESOS-4979)
>> >>   - Memory leak in subprocess. (MESOS-5021)
>> >>
>> >> * Bugs
>> >>   - SSL
>> >>   - Libevent
>> >>   - Fixed point resources math
>> >>   - HDFS
>> >>   - Agent upgrade compatibility
>> >>   - Health checks
>> >>
>> >> New fixes in rc5:
>> >>   - Build failure on OS 10.11 using Xcode 7. (MESOS-3030)
>> >>   - ExamplesTest.PersistentVolumeFramework does not work in OS X El
>> >> Capitan. (MESOS-3604)
>> >>
>> >> Thank you to Evan Krall from Yelp for requesting MESOS-3560 and
>> >> MESOS-3738 to be included,
>> >> and Ben Mahler for requesting MESOS-3030, MESOS-3604, MESOS-4979 and
>> >> MESOS-5021.
>> >>
>> >> The CHANGELOG for the release is available at:
>> >>
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.25.1-rc4
>> >>
>> >>
>> 
>> >>
>> >> The candidate for Mesos 0.25.1 release is available at:
>> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc4/mesos-0.25.1.tar.gz
>> >>
>> >> The tag to be voted on is 0.25.1-rc4:
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.25.1-rc4
>> >>
>> >> The MD5 checksum of the tarball can be found at:
>> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc4/mesos-0.25.1.tar.gz.md5
>> >>
>> >> The signature of the tarball can be found at:
>> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc4/mesos-0.25.1.tar.gz.asc
>> >>
>> >> The PGP key used to sign the release is here:
>> >> https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >>
>> >> The JAR is up in Maven in a staging repository here:
>> >> https://repository.apache.org/content/repositories/orgapachemesos-1136
>> >>
>> >> Please vote on releasing this package as Apache Mesos 0.25.1!
>> >>
>> >> The vote is open until Fri Apr 8 23:59:59 PDT 2016 and passes if a
>> >> majority of at least 3 +1 PMC votes are cast.
>> >>
>> >> [ ] +1 Release this package as Apache Mesos 0.25.1
>> >> [ ] -1 Do not release this package because ...
>> >>
>> >> Thanks,
>> >>
>> >> MPark
>> >>
>> >
>> >
>>
>
>

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

[Kapil Arya]

+1 (binding)

CI runs for amd64/centos/6 amd64/centos/7 amd64/debian/jessie
amd64/ubuntu/precise amd64/ubuntu/trusty amd64/ubuntu/vivid amd64/




On Thu, Apr 7, 2016 at 12:44 AM, Vinod Kone  wrote:

> +1 (binding)
>
> make check on ubuntu 14.04
>
> On Wed, Apr 6, 2016 at 6:17 PM, Benjamin Mahler 
> wrote:
>
>> +1 (binding)
>>
>> The following passes on OS X:
>> $ ./configure CC=clang CXX=clang++ --disable-python --disable-java
>> $ make check
>>
>> On Tue, Apr 5, 2016 at 10:51 PM, Michael Park  wrote:
>>
>>> Hi all,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 0.24.2.
>>>
>>>
>>> 0.24.2 includes the following:
>>>
>>> 
>>> No changes from rc4:
>>>
>>> * Improvements
>>> - Allocator filter performance
>>> - Port Ranges performance
>>> - UUID performance
>>> - `/state` endpoint performance
>>>   - GLOG performance
>>>   - Configurable task/framework history
>>>   - Offer filter timeout fix for backlogged allocator
>>>   - JSON-based credential files. (MESOS-3560)
>>>   - Mesos health check within docker container. (MESOS-3738)
>>>   - Deletion of special files. (MESOS-4979)
>>>   - Memory leak in subprocess. (MESOS-5021)
>>>
>>> * Bugs
>>>   - SSL
>>>   - Libevent
>>>   - Fixed point resources math
>>>   - HDFS
>>>   - Agent upgrade compatibility
>>>   - Health checks
>>>
>>> New fixes in rc5:
>>>   - Build failure on OS 10.11 using Xcode 7. (MESOS-3030)
>>>   - ExamplesTest.PersistentVolumeFramework does not work in OS X El
>>> Capitan. (MESOS-3604)
>>>
>>> Thank you to Evan Krall from Yelp for requesting MESOS-3560 and
>>> MESOS-3738
>>> to be included,
>>> and Ben Mahler for requesting MESOS-3030, MESOS-3604, MESOS-4979 and
>>> MESOS-5021.
>>>
>>> The CHANGELOG for the release is available at:
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.2-rc5
>>>
>>> 
>>>
>>> The candidate for Mesos 0.24.2 release is available at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc5/mesos-0.24.2.tar.gz
>>>
>>> The tag to be voted on is 0.24.2-rc5:
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.2-rc5
>>>
>>> The MD5 checksum of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc5/mesos-0.24.2.tar.gz.md5
>>>
>>> The signature of the tarball can be found at:
>>>
>>> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc5/mesos-0.24.2.tar.gz.asc
>>>
>>> The PGP key used to sign the release is here:
>>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>>
>>> The JAR is up in Maven in a staging repository here:
>>> https://repository.apache.org/content/repositories/orgapachemesos-1134
>>>
>>> Please vote on releasing this package as Apache Mesos 0.24.2!
>>>
>>> The vote is open until Fri Apr 8 23:59:59 PDT 2016 and passes if a
>>> majority
>>> of at least 3 +1 PMC votes are cast.
>>>
>>> [ ] +1 Release this package as Apache Mesos 0.24.2
>>> [ ] -1 Do not release this package because ...
>>>
>>> Thanks,
>>>
>>> MPark
>>>
>>
>>
>

Re: [02/11] mesos git commit: Added support for contender and detector modules.

[Kapil Arya]

Already posted a RR https://reviews.apache.org/r/45876/ :)

On Thu, Apr 7, 2016 at 12:29 PM, James Peach  wrote:

>
> > On Apr 6, 2016, at 3:48 PM, ka...@apache.org wrote:
> >
> > Added support for contender and detector modules.
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/cbbc8f0b/src/tests/module.cpp
> > --
> > diff --git a/src/tests/module.cpp b/src/tests/module.cpp
> > index 8cc305c..4b24048 100644
> > --- a/src/tests/module.cpp
> > +++ b/src/tests/module.cpp
> > @@ -222,6 +222,52 @@ static void addHttpAuthenticatorModules(Modules*
> modules)
> > }
> >
> >
> > +static void addMasterContenderModules(Modules* modules)
> > +{
> > +  CHECK_NOTNULL(modules);
> > +
> > +  const string libraryPath = path::join(
> > +  tests::flags.build_dir,
> > +  "src",
> > +  ".libs",
> > +  os::libraries::expandName("testmastercontender"));
>
> mesos::internal::tests::getModulePath("testmastercontender");
>
>

Re: [proposal] MESOS-4610: MasterContender/MasterDetector should be loadable as modules

[Kapil Arya]

Anurag, Yan,

I can also help in reviewing this stuff. If Yan, has cycles to shepherd it,
great, otherwise, I can shepherd it too.

Best,
Kapil

On Wed, Mar 23, 2016 at 2:38 PM, Anurag Singh <
anurag.prakash.si...@gmail.com> wrote:

> Yan, would you like me to add you as the reviewer on the ReviewBoard
> changes? I'm assuming that you will be the shepherd. Please let me know if
> that isn't confirmed yet.
>
> On Mon, Mar 21, 2016 at 1:08 PM, Benjamin Mahler 
> wrote:
>
> > +Yan
> >
> > On Mon, Mar 21, 2016 at 10:28 AM, Anurag Singh <
> > anurag.prakash.si...@gmail.com> wrote:
> >
> > > Joseph's suggestion is that since Ben Hindman may not have enough time
> to
> > > shepherd this issue, we should seek another one. Would anyone here be
> > able
> > > to shepherd https://issues.apache.org/jira/browse/MESOS-4610?
> > >
> > >
> > > On Tue, Mar 15, 2016 at 1:13 PM, Anurag Singh <
> > > anurag.prakash.si...@gmail.com> wrote:
> > >
> > > > As of now, we've got Ben Hindman as the designated shepherd. Joesph
> Wu
> > > has
> > > > been helping us with the reviews and suggesting changes.
> > > >
> > > > On Tue, Mar 15, 2016 at 1:09 PM, Vinod Kone 
> > > wrote:
> > > >
> > > >> This is great to hear! @YanXu is this something you might be able to
> > > >> shepherd?
> > > >>
> > > >> On Tue, Mar 15, 2016 at 1:03 PM, Anurag Singh <
> > > >> anurag.prakash.si...@gmail.com> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > We're inviting user and developer comments on a series of changes
> we
> > > >> have
> > > >> > been working on that would modularize MasterContender and
> > > >> MasterDetectors.
> > > >> > The goal is to allow the use of detector and contender
> > implementations
> > > >> > other than the ones that are part of Mesos source (Standalone and
> > > >> > Zookeeper). So if one would like to use a custom leader election
> > > >> mechanism
> > > >> > (e.g. one that relies on etcd, consul, etc.), it will be possible
> to
> > > >> load
> > > >> > the implementation from a shared library. In practice, it
> translates
> > > to
> > > >> > using the following command line options:
> > > >> >
> > > >> > For the mesos master:
> > > >> >
> > > >> > --master_contender: The value of this command line option is the
> > name
> > > >> of a
> > > >> > symbol (defined in a module and referenced in the value of the
> > > --modules
> > > >> > flag). The symbol refers to an object of type
> > Module.
> > > >> For
> > > >> > an example, please see the test_contender_module.cpp file in
> > > >> > https://reviews.apache.org/r/44289/.
> > > >> >
> > > >> > For the mesos master and slave:
> > > >> >
> > > >> > --master_detector:  The value of this command line option is the
> > name
> > > >> of a
> > > >> > symbol (defined in a module and referenced in the value of the
> > > --modules
> > > >> > flag). The symbol refers to an object of type
> > Module.
> > > >> For
> > > >> > an example, please see the test_detector_module.cpp file in
> > > >> > https://reviews.apache.org/r/44289/.
> > > >> >
> > > >> > The --modules option, in addition to pointing to the shared
> library
> > > and
> > > >> > symbols, can be used to pass parameters (via the Parameters class)
> > to
> > > >> the
> > > >> > modules in the form of key-value pairs.
> > > >> >
> > > >> > Also, please note that there is no change in the behavior of the
> > > legacy
> > > >> > --zk and --master options. They will continue to work as before.
> > > >> >
> > > >> > The following changes implement this functionality and have been
> > under
> > > >> > review (thanks to Joseph Wu (Mesosphere) for his input):
> > > >> >
> > > >> > https://reviews.apache.org/r/44287/
> > > >> > https://reviews.apache.org/r/44288/
> > > >> > https://reviews.apache.org/r/44543/
> > > >> > https://reviews.apache.org/r/44544/
> > > >> > https://reviews.apache.org/r/44545/
> > > >> > https://reviews.apache.org/r/44546/
> > > >> > https://reviews.apache.org/r/44547/
> > > >> > https://reviews.apache.org/r/44289/
> > > >> > https://reviews.apache.org/r/44669/
> > > >> > https://reviews.apache.org/r/44670/
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

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

[Kapil Arya]

Here is a link to the rpm/deb packages:

http://open.mesosphere.com/downloads/mesos/#apache-mesos-0.28.0

Best,
Kapil

On Thu, Mar 17, 2016 at 2:33 PM, Vinod Kone <vinodk...@gmail.com> wrote:

> +1
>
> @vinodkone
>
> On Mar 17, 2016, at 11:27 AM, Bill Farner <wfar...@apache.org> wrote:
>
> Jake - i think that would be wonderful!
>
> On Thu, Mar 17, 2016 at 11:17 AM, Jake Farrell <jfarr...@apache.org>
> wrote:
>
>> I've been maintaining a deb/rpm set for Mesos and for Aurora and Thrift we
>> have been using the infra supported Bintray to make it available to the
>> community via http://www.apache.org/dist/${project}/${os}
>>
>> If there is interest I'd be happy to put some time into bringing my
>> patches
>> into reviews and helping setup jenkins tests, etc.
>>
>> -Jake
>>
>>
>>
>>
>>
>>
>> On Thu, Mar 17, 2016 at 1:41 PM, Vinod Kone <vinodk...@apache.org> wrote:
>>
>> > The project itself doesn't officially release rpms/debs, but the
>> community
>> > members do.  For example, Mesosphere is planning to release rpms/debs
>> > shortly.
>> >
>> > On Thu, Mar 17, 2016 at 10:38 AM, craig w <codecr...@gmail.com> wrote:
>> >
>> > > Great news. Do the rpm's get automatically built and released or will
>> > they
>> > > come later this week?
>> > >
>> > > On Thu, Mar 17, 2016 at 1:28 PM, Vinod Kone <vinodk...@apache.org>
>> > wrote:
>> > >
>> > >> Hi all,
>> > >>
>> > >>
>> > >> The vote for Mesos 0.28.0 (rc2) has passed with the
>> > >>
>> > >> following votes.
>> > >>
>> > >>
>> > >> +1 (Binding)
>> > >>
>> > >> --
>> > >>
>> > >> Vinod Kone
>> > >>
>> > >> Michael Park
>> > >>
>> > >> Kapil Arya
>> > >>
>> > >>
>> > >> +1 (Non-binding)
>> > >>
>> > >> --
>> > >>
>> > >> Greg Mann
>> > >>
>> > >> Daniel Osborne
>> > >>
>> > >> Jorg Schad
>> > >>
>> > >> Zhitao Li
>> > >>
>> > >>
>> > >> There were no 0 or -1 votes.
>> > >>
>> > >>
>> > >> Please find the release at:
>> > >>
>> > >> https://dist.apache.org/repos/dist/release/mesos/0.28.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=0.28.0
>> > >>
>> > >>
>> > >> The mesos-0.28.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,
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > > https://github.com/mindscratch
>> > > https://www.google.com/+CraigWickesser
>> > > https://twitter.com/mind_scratch
>> > > https://twitter.com/craig_links
>> > >
>> > >
>> >
>>
>
>

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

[Kapil Arya]

+1 (binding).

You can find the links to rpm/deb files for this RC here:

http://open.mesosphere.com/downloads/mesos-rc/

On Thu, Mar 17, 2016 at 12:58 PM, Michael Park  wrote:

> +1 (binding)
>
> Internal CI results with the corresponding JIRA tickets for the failed
> tests:
>
> CentOS 6 (non-SSL):
> CentOS 6 (SSL):
>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> (MESOS-4047 )
>
> CentOS 7 (non-SSL):
>   - ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
> (MESOS-4810)
>
> CentOS 7 (SSL):
>   - LinuxFilesystemIsolatorTest.ROOT_MultipleContainers (Fixed in master)
> (MESOS-4912 )
>   - ProvisionerDockerRegistryPullerTest.ROOT_INTERNET_CURL_ShellCommand
> (MESOS-4810 )
>
> Debian 8 (non-SSL):
>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> (MESOS-4047 )
>
> Debian 8 (SSL):
>   - NsTest.ROOT_setns
> (MESOS-3000 )
>   - MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
> (MESOS-4047 )
>
> Ubuntu 12 (non-SSL):
>   - HealthCheckTest.ROOT_DOCKER_DockerHealthStatusChange
> Failed with MESOS-2017
> 
>
> Ubuntu 12 (SSL): Success!
> Ubuntu 14 (non-SSL): Success!
> Ubuntu 14 (SSL): Success!
> Ubuntu 15 (non-SSL): Success!
> Ubuntu 15 (SSL): Success!
>
> On 11 March 2016 at 15:46, Vinod Kone  wrote:
>
> > Hi all,
> >
> >
> > Please vote on releasing the following candidate as Apache Mesos 0.28.0.
> >
> >
> > 0.28.0 includes the following:
> >
> >
> >
> 
> >
> > Release Notes - Mesos - Version 0.28.0
> >
> > 
> >
> > This release contains the following new features:
> >
> >   * [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 that do their own resource math and
> manipulate
> >
> > fractional resources may observe differences in roundoff error and
> > numerical
> >
> > precision.
> >
> >
> >   * [MESOS-4479] - Reserved resources can now optionally include
> "labels".
> >
> > Labels are a set of key-value pairs that can be used to associate
> > metadata
> >
> > with a reserved resource. For example, frameworks can use this
> feature
> > to
> >
> > distinguish between two reservations for the same role at the same
> > agent
> >
> > that are intended for different purposes.
> >
> >
> >   * [MESOS-2840] - **Experimental** support for container images in Mesos
> >
> > containerizer (a.k.a. Unified Containerizer). This allows frameworks
> to
> >
> > launch Docker/Appc containers using Mesos containerizer without
> relying
> > on
> >
> > docker daemon (engine) or rkt. The isolation of the containers is
> done
> > using
> >
> > isolators. Please refer to docs/container-image.md for currently
> > supported
> >
> > features and limitations.
> >
> >
> >   * [MESOS-4793] - **Experimental** support for v1 Executor HTTP API.
> This
> >
> > allows executors to send HTTP requests to the /api/v1/executor agent
> >
> > endpoint without the need for an executor driver. Please refer to
> >
> > docs/executor-http-api.md for more details.
> >
> >
> >   * [MESOS-4370] Added support for service discovery of Docker containers
> > that
> >
> > use Docker Remote API v1.21.
> >
> >
> > Additional API Changes:
> >
> >   * [MESOS-4066] - Agent should not return partial state when a request
> is
> > made to /state endpoint during recovery.
> >
> >   * [MESOS-4547] - Introduce TASK_KILLING state.
> >
> >   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> > Scheduler API.
> >
> >   * [MESOS-4591] - Change the object 

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

[Kapil Arya]

+1 (Binding)

Successful CI builds for the following distros:

amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid


On Fri, Mar 4, 2016 at 1:06 PM, Vinod Kone  wrote:

> Bad copy paste into the email, sorry. It looks fine in the CHANGELOG.
>
> On Fri, Mar 4, 2016 at 12:52 AM, Shuai Lin  wrote:
>
> >   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> >> Scheduler API.
> >>   * [MESOS-4591] - Change the object of ReserveResources and
> CreateVolume
> >> ACLs to `roles`.
> >>   * [MESOS-4712] - Remove 'force' field from the Subscribe Call in v1
> >> Scheduler API.
> >
> >
> > MESOS-4712 is included twice.
> >
> > On Fri, Mar 4, 2016 at 1:25 PM, Vinod Kone  wrote:
> >
> >> On Thu, Mar 3, 2016 at 5:43 PM, Vinod Kone 
> wrote:
> >>
> >> > Tue Mar  10 17:00:00 PST 2016
> >>
> >>
> >> Sorry. This should be Mar 8th not 10th.
> >>
> >
> >
>

Re: Discussion about upgrading 3rdparty libraries

[Kapil Arya]

>
> *3. 3rdparty/libprocess/3rdparty/stout/tests/protobuf_tests.pb.cc/h
>  files.*
>
> Can anyone tell me why hardcode these two files in Mesos repo? I think
> these two files can be dynamically generated during make check, this will
> make it not depend on protoc version.
>

I think it's just due to the nature of the way dependencies are structured
in 3rdparty. Alex Rukletsov and I thought about fixing it but at that time,
there was some complication due to protoc related dependency paths not
being resolved properly or something like that (I don't remember exactly).
I think there is a way to do it in the current structure, but I strongly
suspect that this will get much better if/when we go ahead with 3rdparty
flattening.

It will be great if you have any other comments, thanks.
>

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

[Kapil Arya]

+1 (binding)

Successful CI builds for the following distros:

amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid

Kapil

On Sat, Feb 27, 2016 at 12:53 AM, Michael Park  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.25.1.
>
>
> 0.25.1 includes the following:
>
> 
>
>- Improvements
>   - `/state` endpoint performance
>   - systemd integration
>   - GLOG performance
>   - Configurable task/framework history
>   - Offer filter timeout fix for backlogged allocator
>
>
>- Bugs
>- SSL
>   - Libevent
>   - Fixed point resources math
>- HDFS
>   - Agent upgrade compatibility
>   - Health checks
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.25.1-rc1
>
> 
>
> The candidate for Mesos 0.25.1 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc1/mesos-0.25.1.tar.gz
>
> The tag to be voted on is 0.25.1-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.25.1-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc1/mesos-0.25.1.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.25.1-rc1/mesos-0.25.1.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1108
>
> Please vote on releasing this package as Apache Mesos 0.25.1!
>
> The vote is open until Wed Mar 2 23:59:59 PST 2016 and passes if a majority
> of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.25.1
> [ ] -1 Do not release this package because ...
>
> Thanks,
>
> Joris, Kapil, MPark
>

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

[Kapil Arya]

+1 (binding)

Successful CI builds for the following distros:

amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid

Kapil

On Sat, Feb 27, 2016 at 12:26 AM, Michael Park  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.26.1.
>
>
> 0.26.1 includes the following:
>
> 
>
>- Improvements
>   - `/state` endpoint performance
>   - systemd integration
>   - GLOG performance
>   - Configurable task/framework history
>   - Offer filter timeout fix for backlogged allocator
>
>
>- Bugs
>- SSL
>   - Libevent
>   - Fixed point resources math
>- HDFS
>   - Agent upgrade compatibility
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.26.1-rc1
>
> 
>
> The candidate for Mesos 0.26.1 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz
>
> The tag to be voted on is 0.26.1-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.26.1-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.26.1-rc1/mesos-0.26.1.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1106
>
> Please vote on releasing this package as Apache Mesos 0.26.1!
>
> The vote is open until Wed Mar 2 23:59:59 PST 2016 and passes if a majority
> of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.26.1
> [ ] -1 Do not release this package because ...
>
> Thanks,
>
> Joris, Kapil, MPark
>

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

[Kapil Arya]

+1 (binding)

Successful CI builds for the following distros:

amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid

Kapil


On Fri, Feb 26, 2016 at 11:54 PM, Michael Park  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.27.2.
>
>
> 0.27.2 includes the following:
>
> 
>
>- MESOS-4693  -
>Variable shadowing in HookManager::slavePreLaunchDockerHook.
>- MESOS-4711  - Race
>condition in libevent poll implementation causes crash.
>- MESOS-4754  - The
>"executors" field is exposed under a backwards incompatible schema.
>- MESOS-4687  -
>Implement reliable floating point for scalar resources.
>
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.2-rc1
>
> 
>
> The candidate for Mesos 0.27.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.2-rc1/mesos-0.27.2.tar.gz
>
> The tag to be voted on is 0.27.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.2-rc1/mesos-0.27.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.2-rc1/mesos-0.27.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1104
>
> Please vote on releasing this package as Apache Mesos 0.27.2!
>
> The vote is open until Wed Mar 2 23:59:59 PST 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.27.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
>
> MPark, Joris, Kapil
>

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

[Kapil Arya]

+1 (binding)

Successful CI builds for the following distros:

amd64/centos/6
amd64/centos/7
amd64/debian/jessie
amd64/ubuntu/precise
amd64/ubuntu/trusty
amd64/ubuntu/vivid

Kapil

On Sat, Feb 27, 2016 at 1:12 AM, Michael Park  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.24.2.
>
>
> 0.24.2 includes the following:
>
> 
>
>- Improvements
>   - Allocator filter performance
>   - Port Ranges performance
>   - UUID performance
>   - `/state` endpoint performance
>   - GLOG performance
>   - Configurable task/framework history
>   - Offer filter timeout fix for backlogged allocator
>
>
>- Bugs
>- SSL
>   - Libevent
>   - Fixed point resources math
>- HDFS
>   - Agent upgrade compatibility
>   - Health checks
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.2-rc1
>
> 
>
> The candidate for Mesos 0.24.2 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc1/mesos-0.24.2.tar.gz
>
> The tag to be voted on is 0.24.2-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.2-rc1
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc1/mesos-0.24.2.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.2-rc1/mesos-0.24.2.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1110
>
> Please vote on releasing this package as Apache Mesos 0.24.2!
>
> The vote is open until Wed Mar 2 23:59:59 PST 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.24.2
> [ ] -1 Do not release this package because ...
>
> Thanks,
>
> Joris, Kapil, MPark
>

Proposing Mesos patch releases 0.24.2 - 0.26.1

[Kapil Arya]

Hi All,

We are planning on doing patch releases from 0.24.2 - 0.26.1. Here is the
exhaustive list of patches for each release:

* Fixes for 0.24.2 only
  + (MESOS-3052 ) Allocator
filter performance fix
  + (MESOS-3051 ) Port
Ranges performance fix
  + (MESOS-3046 ) UUID
performance fix

* Fixes for 0.24.2 and 0.25.1 only
  + (MESOS-4106 ) Health
check failure when killing unhealthy task
  + (MESOS-3605 ,
MESOS-3602 ) HDFS du
failure

* Fixes for 0.24.2, 0.25.1, and 0.26.1
  + (MESOS-920 ) GLOG
performance bug when logging excessive WARNING messages.
  + state.json (MESOS-4235
) state.summary(MESOS-4435
), and raw allocator
(part of MESOS-4505
)  performance
improvements.
  + (MESOS-4582 ) Removal
of duplicate "active" fields from state.json
  + (MESOS-3773 ,
MESOS-4069 ) SSL bug fixes
  + (MESOS-4302 )
Allocator offer timeouts for slow/backlogged allocators
  + (r42320 ) Docker -c flag removal
(to support Docker 1.11+)
  + (MESOS-3834 ) Slave
upgrade framework checkpoint incompatibility

* Fixes for 0.25.1 and 0.26.1 only
  + (MESOS-4636 MESOS-4637
,MESOS-4639
,MESOS-4640
) Several fixes for
better handling of systemd environment

* Fixes for 0.26.1 only
  + (MESOS-4283 ,
MESOS-3605 ,MESOS-3602
,MESOS-4311
) Hadoop output parsing
  + (MESOS-4031 ) Slave
crash due to Docker containerizer
  + (MESOS-4449 )
Segfault during executor startup due to NULL pointer dereference.

Let us know if you have any concerns, or if there are any more critical
patches that should go into any of these patch releases.

Best,
Joris, MPark and Kapil

Re: Reorganize 3rdparty directory

[Kapil Arya]

Thanks for bringing it up Alexander!

I don't have a strong opinion wrt git submodules since I don't have
much experience with them personally. Having said that, I would like
to go conservative on this one (baby steps :-) ).

Further, I do understand that moving libprocess and stout directories
will be painful for people who already have several branches and will
have conflicts. But I do think, there are some interim solutions as
well (for example, move libprocess/stout to wherever we want, but keep
a symlink from 3rdparty/libprocess, etc, to those new locations for
some time). I am sure there are better solutions out there, but this
should work too.

Best,
Kapil

On Tue, Feb 16, 2016 at 12:38 PM, Erik Weathers
<eweath...@groupon.com.invalid> wrote:
> If we go to git submodules, please ensure there are good docs around how to
> update cloned repos.
>
> e.g., From ansible: https://docs.ansible.com/ansible/intro_installation.html
>
> Note when updating ansible, be sure to not only update the source tree, but
> also the “submodules” in git which point at Ansible’s own modules (not the
> same kind of modules, alas).
>
> $ git pull --rebase
> $ git submodule update --init --recursive
>
> Thanks,
>
> - Erik
>
> On Tue, Feb 16, 2016 at 8:54 AM, Alexander Rojas <alexan...@mesosphere.io>
> wrote:
>
>> +1
>> I am one who is totally in for that change. It is not only the directories
>> problem, but the structure which has led that the stout tests (which do
>> need to be compiled) are actually managed in the libprocess Makefile, on
>> top of all the things you have already mentioned.
>>
>>
>> > On 09 Feb 2016, at 17:53, Kapil Arya <ka...@mesosphere.io> wrote:
>> >
>> > On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu <yujie@gmail.com> wrote:
>> >> Kapil,
>> >>
>> >> I guess what I want to understand is why the existing structure makes it
>> >> hard for you to do the things that you want to do (installing
>> >> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as
>> part
>> >> of "make install").
>> >
>> > Let me see if I can answer that :-).
>> >
>> > This is somewhat related. For example, if we want to install protobuf
>> > in 3rdparty/{include,lib} (for module developers to use them without
>> > doing a proper mesos installation), you need to provide the correct
>> > "--prefix" flag that points to 3rdparty/. However, due to multiple
>> > levels of configure.ac, the "--prefix" can at best be generated by
>> > prepending "../../../" to get to the great-grandparent directory. This
>> > is because we have a separate configure.ac which manages
>> > 3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
>> > but they are not clean.
>> >
>> > Similar thing holds for system-wide installation of these 3rdparty
>> > packages. For example, ideally, we would want to use
>> > "${pkglibdir}/3rdparty" as a prefix for those packages. However, since
>> > they are part of libprocess package, we don't get the correct
>> > directory and have to use either hardwired $pkglibdir, or somehow pass
>> > it from the top-level configure all the way down to
>> > 3rdparty/libprocess/3rdparty/Makefile.am :-(.
>> >
>> >
>> >> The only reason you mentioned in the original email is that "in the
>> current
>> >> code base, we don't strictly follow the 3rdparty structure", which IMO
>> is
>> >> not a very convincing reason for such a big change.
>> >
>> > How about a not so big change? :-). What if we just move
>> > 3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
>> > stout as is? That is not a big change since we are not touching
>> > libprocess/stout. Just adjusting Makefiles and I am pretty sure it
>> > will be cleaner and simpler than what we have right now.
>> >
>> > As a later time, we can then consider moving stout out to 3rdparty/
>> > while leaving libprocess as is. But that's something we can decide
>> > later and leave stout as an exception for now.
>> >
>> > BTW, if we were to install all the 3rdparty packages in 3rdparty/,
>> > that would also cut down a lot on the compiler flags (i.e., fewer "-I"
>> > and "-L" flags) :-).
>> >
>> > Kapil
>> >
>> >>
>> >> - Jie
>> >>
>> >> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya <ka...@mesosp

Re: Mesos 0.27.1

[Kapil Arya]

Hi Travis,

It slipped through the cracks, sorry about that!

I have now assigned myself as the shepherd on the Jira ticket and will get
you the feedback on the review request later Today.

Best,
Kapil

On Tue, Feb 9, 2016 at 8:19 AM, Hegner, Travis <theg...@trilliumit.com>
wrote:

> Thanks Adam,
>
> Kapil offered to shepherd it originally, but I haven't heard from him.
> Haosdent has been providing some feedback on the review board, and I have
> addressed all raised issues.
>
> What else can I do to keep it moving?
>
> Travis
>
> -Original Message-
> From: Adam Bordelon [mailto:a...@mesosphere.io]
> Sent: Tuesday, February 9, 2016 2:31 AM
> To: dev <dev@mesos.apache.org>; Tim Chen <t...@mesosphere.io>; Kapil Arya <
> ka...@mesosphere.io>
> Subject: Re: Mesos 0.27.1
>
> Travis, you need to get a committer signed up as the Shepherd for your
> issue, and then they can work the 0.27.1 release manager(s) to decide if
> it's worth blocking the release or at least including.
> Maybe Tim or Kapil would be interested in Shepherding?
>
> On Mon, Feb 8, 2016 at 11:42 AM, Hegner, Travis <theg...@trilliumit.com>
> wrote:
>
> > Any chance to get MESOS-4370 (
> > https://issues.apache.org/jira/browse/MESOS-4370) into this release? I
> > currently have a patch on the review board (
> > https://reviews.apache.org/r/43093/) with no open issues...
> >
> > Should I set the target version for it? What else can I do to get this
> > one moving?
> >
> > Thanks,
> >
> > Travis
> >
> > -Original Message-
> > From: Michael Park [mailto:mp...@apache.org]
> > Sent: Friday, February 5, 2016 3:41 PM
> > To: dev <dev@mesos.apache.org>
> > Subject: Mesos 0.27.1
> >
> > Hello,
> >
> > I've recently been notified that the JSON output from the `/state`
> > endpoint contains duplicate keys which breaks some of the JSON parsing
> > libraries:
> > MESOS-4582 <https://issues.apache.org/jira/browse/MESOS-4582>.
> >
> > I'm proposing to cut a Mesos 0.27.1 for this issue. Joris and I are
> > willing to volunteer as release managers for it. If there are other
> > bugs found in
> > 0.27.0 that you would like to get into 0.27.1, please add the ticket
> > to the dashboard <
> > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=1232
> > 7686
> > >
> >  for 0.27.1 release.
> >
> > Thanks,
> >
> > Joris, MPark.
> >
>

Reorganize 3rdparty directory

[Kapil Arya]

Hi All,

TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into 3rdparty/.
(Optionally) Move libprocess/stout to the top-level directory.

I wanted to start some discussion around reorganizing stuff inside
"3rdparty". I apologize for the length of the email, please bear with me.

Traditionally, 3rdparty has been used to hold all Mesos dependencies
(zookeeper, libprocess, protobuf, stout, etc.). Further,
libprocess/3rdparty was to hold all libprocess dependencies (which may in
turn be Mesos dependencies as well).

As I understand, the original motivation was to emphasize that libprocess
is an independent project which depends on "stout", which in turn is also
an independent project.

However, in the current code base, we don't strictly follow the 3rdparty
structure. For example, stout has a dependency on picojson and
google-protobuf, but we don't put these two packages inside
3rdparty/libprocess/3rdparty/stout/3rdparty/.

In light of these anomalies, I want to propose that we flatten out the
3rdparty directory and put all packages (libprocess, stout, protobuf,
picojson, zookeeper, etc.) at the same level in 3rdparty. We can still use
"--with-XYZ=..." to the full extent as needed.

To take it a step further, I want to propose that we bring libprocess and
stout out of 3rdparty/ and move them at the top level (i.e., make them
peers of src/). That way, all code in 3rdparty/ is stuff from "third"
parties and is used only when "--with-bundled" is defined (by default).
This hierarchy will still allow us to keep libprocess and stout as separate
independent projects.

The motivation for this proposal came when dealing with 3rdparty
dependencies for module development. A module developer needs access to
protobuf, picojson, glog, etc., and for that matter, the exact versions of
these packages that Mesos was compiled with.

We want to solve this problem by installing module-specific 3rdparty
dependencies into "${pkglibdir}/3rdparty" as part of "make install" (if
configured with something like "--enable-install-module-dependencies").
(There is a discussion going on in a separate thread).

Further, as of today, when we install Mesos using "make install", we
install stout headers in "${prefix}/include/stout". However, stout has
dependencies on picojson[1] and google-protobuf headers which may not be
present on the machine. This leaves stout, and in turn libprocess and Mesos
headers, fairly broken. I understand that this issue is somewhat orthogonal
to the main issue being discussed in this mail, but I wanted to put it out
since it's related.

Any thoughts, comments, concerns are most welcome!

Best,
Kapil


[1]: Picojson issue was resolved as part of
https://reviews.apache.org/r/41424/ which installs picojson.h into the
include-dir.

Re: Reorganize 3rdparty directory

[Kapil Arya]

On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu <yujie@gmail.com> wrote:
>
> >
> > However, in the current code base, we don't strictly follow the 3rdparty
> > structure. For example, stout has a dependency on picojson and
> > google-protobuf, but we don't put these two packages inside
> > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
>
>
> My understanding is that stout is header only. So it does not have to
> bundle 3rdparty libraries. The user of stout is responsible for bundling
> them if they are used.


I don't think being header-only is an excuse to have a broken
installation :-). Further, we don't make it easier for the user to get
the 3rdparty binaries either. For example, if the user has a different
version of protobuf installed on the system, the compilation of any
program that uses stout will fail spectacularly!

Having said that, the gist here is that we have somewhat deviated from
original motivation behind the 3rdparty directory and it would be nice
if we can have a flatter structure.

>
>
> - Jie
>
> On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > Hi All,
> >
> > TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into 3rdparty/.
> > (Optionally) Move libprocess/stout to the top-level directory.
> >
> > I wanted to start some discussion around reorganizing stuff inside
> > "3rdparty". I apologize for the length of the email, please bear with me.
> >
> > Traditionally, 3rdparty has been used to hold all Mesos dependencies
> > (zookeeper, libprocess, protobuf, stout, etc.). Further,
> > libprocess/3rdparty was to hold all libprocess dependencies (which may in
> > turn be Mesos dependencies as well).
> >
> > As I understand, the original motivation was to emphasize that libprocess
> > is an independent project which depends on "stout", which in turn is also
> > an independent project.
> >
> > However, in the current code base, we don't strictly follow the 3rdparty
> > structure. For example, stout has a dependency on picojson and
> > google-protobuf, but we don't put these two packages inside
> > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
> >
> > In light of these anomalies, I want to propose that we flatten out the
> > 3rdparty directory and put all packages (libprocess, stout, protobuf,
> > picojson, zookeeper, etc.) at the same level in 3rdparty. We can still use
> > "--with-XYZ=..." to the full extent as needed.
> >
> > To take it a step further, I want to propose that we bring libprocess and
> > stout out of 3rdparty/ and move them at the top level (i.e., make them
> > peers of src/). That way, all code in 3rdparty/ is stuff from "third"
> > parties and is used only when "--with-bundled" is defined (by default).
> > This hierarchy will still allow us to keep libprocess and stout as separate
> > independent projects.
> >
> > The motivation for this proposal came when dealing with 3rdparty
> > dependencies for module development. A module developer needs access to
> > protobuf, picojson, glog, etc., and for that matter, the exact versions of
> > these packages that Mesos was compiled with.
> >
> > We want to solve this problem by installing module-specific 3rdparty
> > dependencies into "${pkglibdir}/3rdparty" as part of "make install" (if
> > configured with something like "--enable-install-module-dependencies").
> > (There is a discussion going on in a separate thread).
> >
> > Further, as of today, when we install Mesos using "make install", we
> > install stout headers in "${prefix}/include/stout". However, stout has
> > dependencies on picojson[1] and google-protobuf headers which may not be
> > present on the machine. This leaves stout, and in turn libprocess and Mesos
> > headers, fairly broken. I understand that this issue is somewhat orthogonal
> > to the main issue being discussed in this mail, but I wanted to put it out
> > since it's related.
> >
> > Any thoughts, comments, concerns are most welcome!
> >
> > Best,
> > Kapil
> >
> >
> > [1]: Picojson issue was resolved as part of
> > https://reviews.apache.org/r/41424/ which installs picojson.h into the
> > include-dir.
> >

Re: Reorganize 3rdparty directory

[Kapil Arya]

On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu <yujie@gmail.com> wrote:
> Kapil,
>
> I guess what I want to understand is why the existing structure makes it
> hard for you to do the things that you want to do (installing
> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part
> of "make install").

Let me see if I can answer that :-).

This is somewhat related. For example, if we want to install protobuf
in 3rdparty/{include,lib} (for module developers to use them without
doing a proper mesos installation), you need to provide the correct
"--prefix" flag that points to 3rdparty/. However, due to multiple
levels of configure.ac, the "--prefix" can at best be generated by
prepending "../../../" to get to the great-grandparent directory. This
is because we have a separate configure.ac which manages
3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
but they are not clean.

Similar thing holds for system-wide installation of these 3rdparty
packages. For example, ideally, we would want to use
"${pkglibdir}/3rdparty" as a prefix for those packages. However, since
they are part of libprocess package, we don't get the correct
directory and have to use either hardwired $pkglibdir, or somehow pass
it from the top-level configure all the way down to
3rdparty/libprocess/3rdparty/Makefile.am :-(.


> The only reason you mentioned in the original email is that "in the current
> code base, we don't strictly follow the 3rdparty structure", which IMO is
> not a very convincing reason for such a big change.

How about a not so big change? :-). What if we just move
3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
stout as is? That is not a big change since we are not touching
libprocess/stout. Just adjusting Makefiles and I am pretty sure it
will be cleaner and simpler than what we have right now.

As a later time, we can then consider moving stout out to 3rdparty/
while leaving libprocess as is. But that's something we can decide
later and leave stout as an exception for now.

BTW, if we were to install all the 3rdparty packages in 3rdparty/,
that would also cut down a lot on the compiler flags (i.e., fewer "-I"
and "-L" flags) :-).

Kapil

>
> - Jie
>
> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu <yujie@gmail.com> wrote:
>> >
>> > >
>> > > However, in the current code base, we don't strictly follow the
>> 3rdparty
>> > > structure. For example, stout has a dependency on picojson and
>> > > google-protobuf, but we don't put these two packages inside
>> > > 3rdparty/libprocess/3rdparty/stout/3rdparty/.
>> >
>> >
>> > My understanding is that stout is header only. So it does not have to
>> > bundle 3rdparty libraries. The user of stout is responsible for bundling
>> > them if they are used.
>>
>>
>> I don't think being header-only is an excuse to have a broken
>> installation :-). Further, we don't make it easier for the user to get
>> the 3rdparty binaries either. For example, if the user has a different
>> version of protobuf installed on the system, the compilation of any
>> program that uses stout will fail spectacularly!
>>
>> Having said that, the gist here is that we have somewhat deviated from
>> original motivation behind the 3rdparty directory and it would be nice
>> if we can have a flatter structure.
>>
>> >
>> >
>> > - Jie
>> >
>> > On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>> >
>> > > Hi All,
>> > >
>> > > TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into
>> 3rdparty/.
>> > > (Optionally) Move libprocess/stout to the top-level directory.
>> > >
>> > > I wanted to start some discussion around reorganizing stuff inside
>> > > "3rdparty". I apologize for the length of the email, please bear with
>> me.
>> > >
>> > > Traditionally, 3rdparty has been used to hold all Mesos dependencies
>> > > (zookeeper, libprocess, protobuf, stout, etc.). Further,
>> > > libprocess/3rdparty was to hold all libprocess dependencies (which may
>> in
>> > > turn be Mesos dependencies as well).
>> > >
>> > > As I understand, the original motivation was to emphasize that
>> libprocess
>> > > is an independent project which depends on "stout", which in turn is
>> also
>> > > an independent project.
>> > 

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

[Kapil Arya]

And here is the ticket tracking the user doc:
https://issues.apache.org/jira/browse/MESOS-4531. Will link to the
blog post once the doc is ready :-).

On Thu, Feb 4, 2016 at 11:38 AM, Jie Yu <yujie@gmail.com> wrote:
> Niklas,
>
> I think Joris is still working on the user doc for multi-disk support in
> Mesos.
>
> - Jie
>
> On Thu, Feb 4, 2016 at 1:22 AM, Niklas Nielsen <n...@qni.dk> wrote:
>
>> Awesome guys!
>>
>> Kapil, we usually linked to the user documentation in the blog to the new
>> features. Do you have a link to the docs on multiple disk resources?
>>
>> On Wed, Feb 3, 2016 at 11:27 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> > And here is the blog post:
>> > http://mesos.apache.org/blog/mesos-0-27-0-released.
>> >
>> > On Wed, Feb 3, 2016 at 4:48 PM, Michael Park <mp...@apache.org> wrote:
>> > > Kapil is currently working on it. We'll publish it shortly :)
>> > >
>> > > On 3 February 2016 at 13:41, Benjamin Mahler <bmah...@apache.org>
>> wrote:
>> > >>
>> > >> Great! Is a blog post on the way?
>> > >>
>> > >> On Sun, Jan 31, 2016 at 5:39 PM, Michael Park <mp...@apache.org>
>> wrote:
>> > >>
>> > >> > Hi all,
>> > >> >
>> > >> > The vote for Mesos 0.27.0 (rc2) has passed with the
>> > >> > following votes.
>> > >> >
>> > >> > +1 (Binding)
>> > >> > --
>> > >> > Vinod Kone
>> > >> > Joris Van Remoortere
>> > >> > Till Toenshoff
>> > >> >
>> > >> > +1 (Non-binding)
>> > >> > --
>> > >> > Jörg Schad
>> > >> > Marco Massenzio
>> > >> > Greg Mann
>> > >> >
>> > >> > There were no 0 or -1 votes.
>> > >> >
>> > >> > Please find the release at:
>> > >> > https://dist.apache.org/repos/dist/release/mesos/0.27.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=0.27.0
>> > >> >
>> > >> > The mesos-0.27.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,
>> > >> >
>> > >> > Tim, Kapil, MPark
>> > >> >
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Niklas
>>

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

[Kapil Arya]

That's a good point, Niklas!

IMO, we should be able to ship a major feature as long as we have an
assurance that the user doc will land in the next few days (not
weeks).

On Thu, Feb 4, 2016 at 11:55 AM, Niklas Nielsen <n...@qni.dk> wrote:
> Thanks Jie and Kapil! Looking forward to it.
>
> I did read the proposal, but playing the devils advocate for a bit; how can
> we ship a 'major feature' without bundled user documentation? Referring to
> tickets and design docs (which may/or may not be the way things ended up
> getting implemented) or to code is not good enough, in my mind.
>
> Should we line up some expectations to available user docs, example
> framework code, etc. before announcing the availability of a feature?
>
> Niklas
>
> On Thu, Feb 4, 2016 at 5:41 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> And here is the ticket tracking the user doc:
>> https://issues.apache.org/jira/browse/MESOS-4531. Will link to the
>> blog post once the doc is ready :-).
>>
>> On Thu, Feb 4, 2016 at 11:38 AM, Jie Yu <yujie@gmail.com> wrote:
>> > Niklas,
>> >
>> > I think Joris is still working on the user doc for multi-disk support in
>> > Mesos.
>> >
>> > - Jie
>> >
>> > On Thu, Feb 4, 2016 at 1:22 AM, Niklas Nielsen <n...@qni.dk> wrote:
>> >
>> >> Awesome guys!
>> >>
>> >> Kapil, we usually linked to the user documentation in the blog to the
>> >> new
>> >> features. Do you have a link to the docs on multiple disk resources?
>> >>
>> >> On Wed, Feb 3, 2016 at 11:27 PM, Kapil Arya <ka...@mesosphere.io>
>> >> wrote:
>> >>
>> >> > And here is the blog post:
>> >> > http://mesos.apache.org/blog/mesos-0-27-0-released.
>> >> >
>> >> > On Wed, Feb 3, 2016 at 4:48 PM, Michael Park <mp...@apache.org>
>> >> > wrote:
>> >> > > Kapil is currently working on it. We'll publish it shortly :)
>> >> > >
>> >> > > On 3 February 2016 at 13:41, Benjamin Mahler <bmah...@apache.org>
>> >> wrote:
>> >> > >>
>> >> > >> Great! Is a blog post on the way?
>> >> > >>
>> >> > >> On Sun, Jan 31, 2016 at 5:39 PM, Michael Park <mp...@apache.org>
>> >> wrote:
>> >> > >>
>> >> > >> > Hi all,
>> >> > >> >
>> >> > >> > The vote for Mesos 0.27.0 (rc2) has passed with the
>> >> > >> > following votes.
>> >> > >> >
>> >> > >> > +1 (Binding)
>> >> > >> > --
>> >> > >> > Vinod Kone
>> >> > >> > Joris Van Remoortere
>> >> > >> > Till Toenshoff
>> >> > >> >
>> >> > >> > +1 (Non-binding)
>> >> > >> > --
>> >> > >> > Jörg Schad
>> >> > >> > Marco Massenzio
>> >> > >> > Greg Mann
>> >> > >> >
>> >> > >> > There were no 0 or -1 votes.
>> >> > >> >
>> >> > >> > Please find the release at:
>> >> > >> > https://dist.apache.org/repos/dist/release/mesos/0.27.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=0.27.0
>> >> > >> >
>> >> > >> > The mesos-0.27.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,
>> >> > >> >
>> >> > >> > Tim, Kapil, MPark
>> >> > >> >
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Niklas
>> >>
>
>
>
>
> --
> Niklas

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

[Kapil Arya]

And here is the blog post: http://mesos.apache.org/blog/mesos-0-27-0-released.

On Wed, Feb 3, 2016 at 4:48 PM, Michael Park  wrote:
> Kapil is currently working on it. We'll publish it shortly :)
>
> On 3 February 2016 at 13:41, Benjamin Mahler  wrote:
>>
>> Great! Is a blog post on the way?
>>
>> On Sun, Jan 31, 2016 at 5:39 PM, Michael Park  wrote:
>>
>> > Hi all,
>> >
>> > The vote for Mesos 0.27.0 (rc2) has passed with the
>> > following votes.
>> >
>> > +1 (Binding)
>> > --
>> > Vinod Kone
>> > Joris Van Remoortere
>> > Till Toenshoff
>> >
>> > +1 (Non-binding)
>> > --
>> > Jörg Schad
>> > Marco Massenzio
>> > Greg Mann
>> >
>> > There were no 0 or -1 votes.
>> >
>> > Please find the release at:
>> > https://dist.apache.org/repos/dist/release/mesos/0.27.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=0.27.0
>> >
>> > The mesos-0.27.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,
>> >
>> > Tim, Kapil, MPark
>> >
>
>

Re: Shephard Reqeust: patch for MESOS-4370

[Kapil Arya]

Thanks for the explanation, Greg!!

Travis,

Thanks for contributing to Mesos. Please go through the contributor
guidelines as suggested by
Greg. I can then shepherd the patch for you.

Best,
Kapil


On Tue, Feb 2, 2016 at 2:56 PM, Greg Mann  wrote:
> Hi Travis,
> Thanks for your contribution! It's always great to see new contributors :-)
>
> A couple things regarding your patch:
> Please have a look at the contribution guidelines here:
> http://mesos.apache.org/documentation/latest/submitting-a-patch/
>
> The standard protocol when addressing a JIRA issue is to assign the issue
> to yourself on JIRA, and then find a "Shepherd" for the ticket before
> coding begins. The shepherd is a Mesos committer who will work with you to
> design the patch, and then commit it once it's complete.
>
> It also looks like the ticket you've been working on is currently in the
> "Open" state. This means that it hasn't been marked as "Accepted" by an
> existing contributor, signifying that someone thinks it's an issue worth
> pursuing. In this case, the first step is to begin a discussion on the
> issue by commenting on JIRA, and perhaps drawing attention to it via this
> mailing list, to see how the community thinks we should proceed.
>
> I would recommend that you first assign MESOS-4370 to yourself (this will
> require contributor permissions on JIRA, which can be secured with a short
> email to this mailing list requesting them). You already did a good job of
> summarizing your approach in the description of your review request, which
> you also posted on JIRA, so hopefully this thread will draw the attention
> of some interested parties who can provide some feedback, as well as a
> committer who might have some time to shepherd the ticket for you :-)
>
> Cheers, and welcome!
> Greg
>
>
> On Tue, Feb 2, 2016 at 11:18 AM, Hegner, Travis 
> wrote:
>
>> Hello All,
>>
>> I am requesting a review of a patch to MESOS-4370. Here are all of the
>> pertinent links:
>>
>> https://issues.apache.org/jira/browse/MESOS-4370
>> https://reviews.apache.org/r/43093/
>> https://github.com/apache/mesos/pull/90
>>
>> I have tagged Benjamin Hindman as a reviewer already on the review board
>> as he was listed as the maintainer of the Docker containerizer. I have not
>> had any previous contact with him. My apologies if this is bad etiquette.
>>
>> The patch eliminates the use of the deprecated "NetworkSettings.IPAddress"
>> field in the docker inspect output, and replaces it with using the
>> appropriate "NetworkSettings.Networks..IPAddress" field, where 
>> is the name of the network as it was passed to the last "--net " on
>> the docker run command. The network name is available and queried from the
>> "HostConfig.NetworkMode" field in the inspect output.
>>
>> Thanks,
>> Travis Hegner
>>

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

On Wed, Jan 27, 2016 at 8:04 AM, Alexander Rojas
<alexan...@mesosphere.io> wrote:
> While valid, I feel that is a very un-unix way of doing this. There are a 
> couple of ideas from me here.
>
> 1. We should separate between a dev release and a normal release. The dev 
> release will include headers for people who want to build modules and other 
> mesos stuff, and the normal release only includes the executables.

The dev and normal releases are from the packaging point of view, when
someone installs pre-compiled Mesos binaries. Here we are talking
about users who run `./configure; make; make install`. For packaging,
I totally agree that we shouldn't bundle the 3rdparty stuff (and
distros won't let us do that anyways).

> 2. When building Mesos, we should avoid exporting unnecessary symbols. This 
> happens to me when building a framework which used a newer version of boost, 
> but when trying to link to mesos, it was taken boost symbols from Mesos, 
> rather annoying (I gave up at the end). I had this problem in the past but I 
> just cannot remember how it was solved.

True. The boost problem that you encountered is exactly the kind of
problem this effort is trying to address.
>
> With respect to Alex issue, I don’t see them as much of a problem as long as 
> we keep the standard behavior of the `--prefix` flag, which allows 
> installation of different versions in different directores.

Yup, we are not proposing to change any semantics of --prefix at all.

>
>
>> On 26 Jan 2016, at 19:54, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> Thanks for the feedback, Alex! I have inlined my responses.
>>
>>> First, I think we should support two use cases: installing 3rdparty
>>> packages and exposing them in the local build. As a Mesos (module)
>>> developer, I may have different versions of Mesos on my machine and I
>>> install neither of them to avoid conflicts. If I develop a module for a
>>> particular Mesos version (i.e. build), I would like to use artifacts of
>>> that build without installing them anywhere.
>>
>> That's a valid use case. How about "installing" the 3rdparty packages
>> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
>> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
>> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
>> modules? We can also update libprocess/Mesos to also use these
>> locations instead of passing a dozen "-I" and "-L" flags during
>> compilation. I am guessing this won't be too intrusive to the overall
>> build system.
>>
>>> Second, additionally 3rdparty packages, how about modules we provide with
>>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>>> refactor default implementations into modules (e.g. hierarchical
>>> allocator), we should install them somewhere.
>>
>> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
>> for it :-). We should just install them in $(pkglibdir). That's the
>> default location for distro packaging as well. That's not too hard to
>> do. Just that we need to decide which modules should be installed.
>>
>> Best,
>> Kapil
>>
>>
>>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>>>
>>>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio <m.massen...@gmail.com>
>>>> wrote:
>>>>> Great thinking, Kapil!
>>>>> (I'm one who got the headache :)
>>>>>
>>>>> However, having recently gone through the effort of having to figure out
>>>> it
>>>>> all, my +1 goes for *good documentation* of what is necessary.
>>>>
>>>> Totally with you on this :)
>>>>
>>>>
>>>>> When installing stuff / magic happening behind the scenes, it is always
>>>>> difficult to ensure it works on all "supported" platforms (and let's not
>>>>> even go into non-supported ones) and we would also run the risk that
>>>> future
>>>>> changes may inadvertently break it.
>>>>>
>>>>> Bear also in mind that folks (who may not be using the --prefix) may be
>>>>> "surprised" to find incompatible/unexpected versions of
>>>> glog/protobuf/etc.
>>>>> in the /usr/local system dir.
>>>>
>>>> This is the reason why we want to put it inside Mesos "owned"
>>>> directories (e.g., /usr/local/include/mesos/3rdparty,
>>>> /usr/lib64/meso

Re: Need a shepherd for MESOS--3317

[Kapil Arya]

Hi Abhishek,

I can shepherd this for you. Please add me to the RR.

Kapil

On Wed, Jan 27, 2016 at 12:31 AM, Abhishek Dasgupta
 wrote:
> Vinod, Can you point me someone whom I can ask for the review?
>
>
> On Wednesday 27 January 2016 12:07 AM, Vinod Kone wrote:
>>
>> Sorry Abhishek, I don't have cycles :(
>>
>> On Tue, Jan 26, 2016 at 3:18 AM, Abhishek Dasgupta <
>> a10gu...@linux.vnet.ibm.com> wrote:
>>
>>> Hi Vinod,
>>>
>>> Can you review the patch https://reviews.apache.org/r/42794/ ? Or, if you
>>> can delegate someone else to review the patch. This is my first review
>>> request in mesos. Thank you.
>>>
>>>
>>> On Thursday 21 January 2016 03:11 PM, Abhishek Dasgupta wrote:
>>>
 Hi,

 Can anybody please shepherd for
 https://issues.apache.org/jira/browse/MESOS-3317 ?


>>> --
>>>Regards,
>>>
>>>
>>>
>>> ---
>>>Abhishek Dasgupta
>>>Linux Software Developer - Linux Technology Centre
>>>IBM Systems Lab,
>>>IBM India Pvt. Ltd.
>>>Embassy Golf Link, D Block
>>>Koramongala - Off Indiranagar Ring Road
>>>Bangalore - 560 071
>>>Mobile: +91-8884107981
>>>
>>>
>>> ---
>>>
>>>
>
> --
>   Regards,
>
>
> ---
>   Abhishek Dasgupta
>   Linux Software Developer - Linux Technology Centre
>   IBM Systems Lab,
>   IBM India Pvt. Ltd.
>   Embassy Golf Link, D Block
>   Koramongala - Off Indiranagar Ring Road
>   Bangalore - 560 071
>   Mobile: +91-8884107981
>
> ---
>

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

Thanks for the feedback, Alex! I have inlined my responses.

> First, I think we should support two use cases: installing 3rdparty
> packages and exposing them in the local build. As a Mesos (module)
> developer, I may have different versions of Mesos on my machine and I
> install neither of them to avoid conflicts. If I develop a module for a
> particular Mesos version (i.e. build), I would like to use artifacts of
> that build without installing them anywhere.

That's a valid use case. How about "installing" the 3rdparty packages
by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
"$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
modules? We can also update libprocess/Mesos to also use these
locations instead of passing a dozen "-I" and "-L" flags during
compilation. I am guessing this won't be too intrusive to the overall
build system.

> Second, additionally 3rdparty packages, how about modules we provide with
> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
> refactor default implementations into modules (e.g. hierarchical
> allocator), we should install them somewhere.

We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
for it :-). We should just install them in $(pkglibdir). That's the
default location for distro packaging as well. That's not too hard to
do. Just that we need to decide which modules should be installed.

Best,
Kapil


> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio <m.massen...@gmail.com>
>> wrote:
>> > Great thinking, Kapil!
>> > (I'm one who got the headache :)
>> >
>> > However, having recently gone through the effort of having to figure out
>> it
>> > all, my +1 goes for *good documentation* of what is necessary.
>>
>> Totally with you on this :)
>>
>>
>> > When installing stuff / magic happening behind the scenes, it is always
>> > difficult to ensure it works on all "supported" platforms (and let's not
>> > even go into non-supported ones) and we would also run the risk that
>> future
>> > changes may inadvertently break it.
>> >
>> > Bear also in mind that folks (who may not be using the --prefix) may be
>> > "surprised" to find incompatible/unexpected versions of
>> glog/protobuf/etc.
>> > in the /usr/local system dir.
>>
>> This is the reason why we want to put it inside Mesos "owned"
>> directories (e.g., /usr/local/include/mesos/3rdparty,
>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>> free for other applications/packages installed on the system.
>>
>> > We could also provide "exemplary scripts" that automate (most of) the
>> > tedious work and example build files, alongside documentation.
>> > If folks agree that this is a desirable alternative, I'm happy to help
>> out
>> > - as mentioned, I've recently been through this, so memory is still
>> fresh.
>>
>> I think several of us have developed such scripts by now. However, the
>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>> component is updated in Mesos :-/.
>>
>> >
>> > My 2c.
>> >
>> > --
>> > *Marco Massenzio*
>> > http://codetrips.com
>> >
>> > On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya <ka...@mesosphere.io>
>> wrote:
>> >
>> >> On Tue, Jan 19, 2016 at 11:58 PM, James Peach <jor...@gmail.com> wrote:
>> >> >
>> >> >> On Jan 19, 2016, at 2:03 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>> >> >>
>> >> >> Hi All,
>> >> >>
>> >> >> I wanted to get your opinion on installing the 3rdparty packages
>> glog,
>> >> >> protobuf, boost and picojson[1] when installing Mesos itself. These
>> >> >> packages are required to build Mesos modules.
>> >> >
>> >> > An alternative approach could be to hide these headers so they are
>> >> internal to Mesos and not incidentally required by innocent modules.
>> IIRC
>> >> this should be fairly easy for picojson, but (much) harder for glog,
>> >> protobuf and boost.
>> >>
>> >> That's a lot of work and super hard to maintain IMHO :(.
>> >>
>> >> >> Currently, a module write has to manually install these 3rdparty
&g

Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

Hi All,

I wanted to get your opinion on installing the 3rdparty packages glog,
protobuf, boost and picojson[1] when installing Mesos itself. These
packages are required to build Mesos modules.

Currently, a module write has to manually install these 3rdparty
packages, either system-wide or locally, and update the compilation
flags such as CPPFLAGS to point to the installation which is
error-prone. Further, one might have a system-wide installation with
the wrong package version, causing even more headache.

The proposal here is to install these 3rdparty packages when
installing Mesos. To avoid any conflicts with system-wide or local
installation, we can install them as follows:

${PREFIX}/include/mesos/3rdparty -- for header files
${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
lib or lib64 depending upon the installation)

where PREFIX refers to the `--prefix` flag for Mesos configure script.

We would then update `mesos.pc` with the correct flags so that a
module write can simply use `pkg-config` to get all the required
flags.

I have created an issue
https://issues.apache.org/jira/browse/MESOS-4434 to track this.

Best,
Kapil


[1]: picojson is currently installed in ${PREFIX}/include. See
https://issues.apache.org/jira/browse/MESOS-3909

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

On Tue, Jan 19, 2016 at 11:58 PM, James Peach <jor...@gmail.com> wrote:
>
>> On Jan 19, 2016, at 2:03 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>>
>> Hi All,
>>
>> I wanted to get your opinion on installing the 3rdparty packages glog,
>> protobuf, boost and picojson[1] when installing Mesos itself. These
>> packages are required to build Mesos modules.
>
> An alternative approach could be to hide these headers so they are internal 
> to Mesos and not incidentally required by innocent modules. IIRC this should 
> be fairly easy for picojson, but (much) harder for glog, protobuf and boost.

That's a lot of work and super hard to maintain IMHO :(.

>> Currently, a module write has to manually install these 3rdparty
>> packages, either system-wide or locally, and update the compilation
>> flags such as CPPFLAGS to point to the installation which is
>> error-prone. Further, one might have a system-wide installation with
>> the wrong package version, causing even more headache.
>
> If you are looking at this, could you please also look at these:
> https://issues.apache.org/jira/browse/MESOS-2537
> https://issues.apache.org/jira/browse/MESOS-4096
>
> MESOS-2537 provides consistent behaviour for building against optionally 
> bundled dependencies (and fixes the --enable-foo semantics).

I'll take a look at this one.

> MESOS-4096 makes it impossible to run stout tests against a protobuf that is 
> not version 2.5.0.

At some point, AlexR and I tried to work on it, but with the stout
directory structure, it got harder to fix then it seemed at first.

>
>> The proposal here is to install these 3rdparty packages when
>> installing Mesos. To avoid any conflicts with system-wide or local
>> installation, we can install them as follows:
>>
>> ${PREFIX}/include/mesos/3rdparty -- for header files
>> ${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
>> lib or lib64 depending upon the installation)
>>
>> where PREFIX refers to the `--prefix` flag for Mesos configure script.
>>
>> We would then update `mesos.pc` with the correct flags so that a
>> module write can simply use `pkg-config` to get all the required
>> flags.
>>
>> I have created an issue
>> https://issues.apache.org/jira/browse/MESOS-4434 to track this.
>>
>> Best,
>> Kapil
>>
>>
>> [1]: picojson is currently installed in ${PREFIX}/include. See
>> https://issues.apache.org/jira/browse/MESOS-3909
>

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

On Tue, Jan 19, 2016 at 9:08 PM, zhiwei <zhiw...@gmail.com> wrote:
> Hi Kapil,
>
> There are two methods to build Mesos modules, one is using installed Mesos
> files, the other is using compiled Mesos files.

The second method is a hack because the first method is not foolproof.
Ideally, one should be able to build a module without having to
decipher the internal directory layout, etc., of Mesos build dir.

>
> Your proposal only affect the first method.
>
> I don't think packaging 3dparty libraries to Mesos is a good solution if
> the 3rdparty libraries have their own standard package(rpm or deb), we
> should document the 3rdparty libraries to let users install them.

That exactly is the problem. If the standard installed versions are
different (as noted in the follow up emails), it's not possible to
compile the module at all.

> Since picojson has not a standard package, so we can include it in Mesos.
> But for others, I prefer to let users install them when they need.
>
>
> Thanks,
> Zhiwei
>
> On Wed, Jan 20, 2016 at 6:03 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> Hi All,
>>
>> I wanted to get your opinion on installing the 3rdparty packages glog,
>> protobuf, boost and picojson[1] when installing Mesos itself. These
>> packages are required to build Mesos modules.
>>
>> Currently, a module write has to manually install these 3rdparty
>> packages, either system-wide or locally, and update the compilation
>> flags such as CPPFLAGS to point to the installation which is
>> error-prone. Further, one might have a system-wide installation with
>> the wrong package version, causing even more headache.
>>
>> The proposal here is to install these 3rdparty packages when
>> installing Mesos. To avoid any conflicts with system-wide or local
>> installation, we can install them as follows:
>>
>> ${PREFIX}/include/mesos/3rdparty -- for header files
>> ${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
>> lib or lib64 depending upon the installation)
>>
>> where PREFIX refers to the `--prefix` flag for Mesos configure script.
>>
>> We would then update `mesos.pc` with the correct flags so that a
>> module write can simply use `pkg-config` to get all the required
>> flags.
>>
>> I have created an issue
>> https://issues.apache.org/jira/browse/MESOS-4434 to track this.
>>
>> Best,
>> Kapil
>>
>>
>> [1]: picojson is currently installed in ${PREFIX}/include. See
>> https://issues.apache.org/jira/browse/MESOS-3909
>>

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio <m.massen...@gmail.com> wrote:
> Great thinking, Kapil!
> (I'm one who got the headache :)
>
> However, having recently gone through the effort of having to figure out it
> all, my +1 goes for *good documentation* of what is necessary.

Totally with you on this :)


> When installing stuff / magic happening behind the scenes, it is always
> difficult to ensure it works on all "supported" platforms (and let's not
> even go into non-supported ones) and we would also run the risk that future
> changes may inadvertently break it.
>
> Bear also in mind that folks (who may not be using the --prefix) may be
> "surprised" to find incompatible/unexpected versions of glog/protobuf/etc.
> in the /usr/local system dir.

This is the reason why we want to put it inside Mesos "owned"
directories (e.g., /usr/local/include/mesos/3rdparty,
/usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
free for other applications/packages installed on the system.

> We could also provide "exemplary scripts" that automate (most of) the
> tedious work and example build files, alongside documentation.
> If folks agree that this is a desirable alternative, I'm happy to help out
> - as mentioned, I've recently been through this, so memory is still fresh.

I think several of us have developed such scripts by now. However, the
problem is maintainability as they get out-of-sync whenever a 3rdparty
component is updated in Mesos :-/.

>
> My 2c.
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
>> On Tue, Jan 19, 2016 at 11:58 PM, James Peach <jor...@gmail.com> wrote:
>> >
>> >> On Jan 19, 2016, at 2:03 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> I wanted to get your opinion on installing the 3rdparty packages glog,
>> >> protobuf, boost and picojson[1] when installing Mesos itself. These
>> >> packages are required to build Mesos modules.
>> >
>> > An alternative approach could be to hide these headers so they are
>> internal to Mesos and not incidentally required by innocent modules. IIRC
>> this should be fairly easy for picojson, but (much) harder for glog,
>> protobuf and boost.
>>
>> That's a lot of work and super hard to maintain IMHO :(.
>>
>> >> Currently, a module write has to manually install these 3rdparty
>> >> packages, either system-wide or locally, and update the compilation
>> >> flags such as CPPFLAGS to point to the installation which is
>> >> error-prone. Further, one might have a system-wide installation with
>> >> the wrong package version, causing even more headache.
>> >
>> > If you are looking at this, could you please also look at these:
>> > https://issues.apache.org/jira/browse/MESOS-2537
>> > https://issues.apache.org/jira/browse/MESOS-4096
>> >
>> > MESOS-2537 provides consistent behaviour for building against optionally
>> bundled dependencies (and fixes the --enable-foo semantics).
>>
>> I'll take a look at this one.
>>
>> > MESOS-4096 makes it impossible to run stout tests against a protobuf
>> that is not version 2.5.0.
>>
>> At some point, AlexR and I tried to work on it, but with the stout
>> directory structure, it got harder to fix then it seemed at first.
>>
>> >
>> >> The proposal here is to install these 3rdparty packages when
>> >> installing Mesos. To avoid any conflicts with system-wide or local
>> >> installation, we can install them as follows:
>> >>
>> >> ${PREFIX}/include/mesos/3rdparty -- for header files
>> >> ${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
>> >> lib or lib64 depending upon the installation)
>> >>
>> >> where PREFIX refers to the `--prefix` flag for Mesos configure script.
>> >>
>> >> We would then update `mesos.pc` with the correct flags so that a
>> >> module write can simply use `pkg-config` to get all the required
>> >> flags.
>> >>
>> >> I have created an issue
>> >> https://issues.apache.org/jira/browse/MESOS-4434 to track this.
>> >>
>> >> Best,
>> >> Kapil
>> >>
>> >>
>> >> [1]: picojson is currently installed in ${PREFIX}/include. See
>> >> https://issues.apache.org/jira/browse/MESOS-3909
>> >
>>

Re: Add JIRA ticket# to `TODO`s in comments

[Kapil Arya]

Hi Ben,

On Wed, Nov 11, 2015 at 8:33 AM, Benjamin Mahler <benjamin.mah...@gmail.com>
wrote:

> Kapil would you mind clarifying what is being proposed here? Folks are
> already free to include a reference to a ticket when writing a comment or a
> TODO, so is the suggestion here to require it for TODOs? Or to add a syntax
> for this? If it's the latter, what does the syntax achieve?
>

The proposal is two fold:

A. Make it mandatory to include a JIRA ticket number with the TODO.

B. Add a syntax for this and for that we need some consensus. I proposed
two options in the initial email:
1. TODO(:MESOS-XXX)
2. TODO(MESOS-XXX)

I personally prefer the second option, since the `REPORTER' is already
covered as part of the Jira ticket.

Kapil


> On Wed, Nov 11, 2015 at 4:29 AM, Klaus Ma <klaus1982...@gmail.com> wrote:
>
> > +1, JIRA will include more discussion and we can close it when it has
> been
> > improved.
> >
> > 
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >
> > On Wed, Nov 11, 2015 at 5:11 PM, Alexander Rojas <
> alexan...@mesosphere.io>
> > wrote:
> >
> > > +1
> > >
> > > This also provides a way of removing TODO’s since they are traceable.
> If
> > > you look in the code, there are TODO’s which are no relevant anymore or
> > > probably cannot be understood from their actual context.
> > >
> > > > On 08 Nov 2015, at 05:50, Kapil Arya <ka...@mesosphere.io> wrote:
> > > >
> > > > Folks,
> > > >
> > > > I wanted to bring up a style issue related to the TODO tag in
> > comments. I
> > > > have filed a Jira ticket (
> > > https://issues.apache.org/jira/browse/MESOS-3850)
> > > > with the following description:
> > > >
> > > > Currently, we have a TODO() tags to note
> > > stuff
> > > > has "should be"/"has to be" done in future. While this provides us
> with
> > > > some notion of accounting, it's not enough.
> > > >
> > > > The author listed in the TODO comment should be considered the
> > > "Reporter",
> > > > but not necessarily the "Assignee". Further, since the stuff "should
> > > > be"/"has to be" done, why not have a Jira issue tracking it?
> > > >
> > > > We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or something
> > > > similar. Finally, we might wan to consider adding this to the style
> > guide
> > > > to make it a soft/hard requirement.
> > > >
> > > >
> > > > Are there any opinions/suggestions on this one?
> > > >
> > > > Best,
> > > > Kapil
> > >
> > >
> >
>

Add JIRA ticket# to `TODO`s in comments

[Kapil Arya]

Folks,

I wanted to bring up a style issue related to the TODO tag in comments. I
have filed a Jira ticket (https://issues.apache.org/jira/browse/MESOS-3850)
with the following description:

Currently, we have a TODO() tags to note stuff
has "should be"/"has to be" done in future. While this provides us with
some notion of accounting, it's not enough.

The author listed in the TODO comment should be considered the "Reporter",
but not necessarily the "Assignee". Further, since the stuff "should
be"/"has to be" done, why not have a Jira issue tracking it?

We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or something
similar. Finally, we might wan to consider adding this to the style guide
to make it a soft/hard requirement.


Are there any opinions/suggestions on this one?

Best,
Kapil

Re: Mesos Style Guideline Adjustments

[Kapil Arya]

As far as setting a soft limit goes, I think there are several different
style guides and it basically boils down to personal preferences as well.
The Linux `fmt` command wraps by 75 columns by default; others use 72 or as
extreme as 60 columns.

Having said that, it's nice to have tools that enforce some
check. Jaggedness isn't pretty and one can always use their judgement to
reformat the comments to make it look nicer and more readable.

My 2 cents.

On Fri, Nov 6, 2015 at 2:26 PM, Joris Van Remoortere 
wrote:

> @ben Is "jaggedness" the only *formatting* influence on the readability of
> the comments? If so, would it be possible to make a simple github.io page
> where we can paste comments, and they get formatted for minimal jaggedness
> based on some simple math? This would help provide consistency between
> contributions, and likely better results than humans trying to optimize the
> jaggedness equation.
>
> This way we can focus on the content of the comments when reviewing, rather
> than the format. Later one we might even be able to incorporate this in
> more intelligent editor friendly formatting tools.
>
> If there is more than some simple math involved, this may not be a viable
> solution.
>
> Joris
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Fri, Nov 6, 2015 at 11:10 AM, Benjamin Mahler <
> benjamin.mah...@gmail.com>
> wrote:
>
> > I raise this because there is a ton of value in keeping our codebase as
> > readable as possible. Having had to navigate and maintain the code base
> for
> > the past few years, this _is_ a "real issue" that deserves the
> contributors
> > spending their mental resources on. I realize this seems very subtle, but
> > it is of critical importance for the maintainability of the project that
> > folks are paying attention to how their code and comments will be read by
> > others.
> >
> > I think about this as follows: we'll always have "soft" rules that cannot
> > be enforced by these style checkers but require mentorship to communicate
> > as we grow the community. These tools cannot tell you how to structure
> your
> > code in a simple form. They also can't tell you how to write a comment
> in a
> > way that is clear to others.
> >
> > To Alex's example, two comments:
> >
> > (1) The second comment is poorly written, did no one even notice this??
> > That's a "real issue" :(
> > (2) It's important not to isolate the comments from the code. The
> comments
> > live with the code and a major reason why long line length paragraphs are
> > irregular is because the majority of code lines do not approach 80
> > characters.
> > (3) We tend to separate "multiple logical parts" of a comment with an
> empty
> > // line, which helps readability.
> > (4) I'm not saying wrap at 70 or at 80, but (a) write and wrap to reduce
> > "jaggedness" (or to increase "regularity") and (b) long line lengths (80)
> > for large paragraphs are harder to read.
> >
> > I just don't want the formatter to become a crutch that causes folks to
> > think less about the implications of how they write their comments. Do
> the
> > soft rules in (a) and (b) seem reasonable? We already need to be diligent
> > in reviews to ensure that comments are well-written.
> >
> > On Fri, Nov 6, 2015 at 8:44 AM, Benjamin Bannier <
> > benjamin.bann...@mesosphere.io> wrote:
> >
> > > Hi,
> > >
> > > just to echo Alexander’s point, for newbies like me being able to
> > delegate
> > > formatting decisions to tools as much as possible frees up a lot of
> > mental
> > > resources for tackling the real issues.
> > >
> > >
> > > Cheers,
> > >
> > > Benjamin
> > >
> > > ps. Also looking forward to an updated and expanded clang-format
> config.
> > >
> > >
> > > > On Nov 6, 2015, at 1:44 PM, Alexander Rojas  >
> > > wrote:
> > > >
> > > > I think one of the main reasons we move to having 80 as the limit for
> > > both code and comments is the ability it gives us to use tools (e.g.
> > > clang-format) to enforce formatting rules, so personally I rather have
> us
> > > putting effort towards that goal. On that note, the developer branch of
> > > clang-format allows a much closer formatting options to the ones we
> use.
> > On
> > > OS X it can be installed using `brew install --HEAD clang-format`.
> > > >
> > > > Right now I’m working on setting the config file to be as close as
> > > possible to our style.
> > > >
> > > >> On 06 Nov 2015, at 10:09, Alex Rukletsov 
> wrote:
> > > >>
> > > >> I think jaggedness in the example you provide comes mainly from the
> > fact
> > > >> that the second comment has multiple logical blocks. I have
> formatted
> > > both
> > > >> comments at 70 and at 80, here is the outcome:
> > > http://pastebin.com/nRQB0nCD
> > > >>
> > > >> While the first comment indeed looks better when wrapped at 70, I
> > can't
> > > say
> > > >> the same about the second one.
> > > >>
> > > >> I would say, that the longer a line could be, the 

Re: Proposal: move towards #pragma and away from #include guards

[Kapil Arya]

+1.

I think we should do it all at once as Artem mentioned. This doesn't really
affect the history (git-blame, etc.) because we are not touching code per
se.

On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan 
wrote:

> Hi Alex,
>
> While I agree with the idea in general, I strongly believe that we should
> either leave it as it is or fix everything in one go (i.e. three
> consecutive commits). Having both #include guards and #pragmas in the
> codebase will be confusing and untidy. We have done code sweeps like this
> in the past when we had to introduce changes to the style guide, so if
> folks agree you just need to find a shepherd and do it :).
>
> Cheers,
> Artem.
>
> On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer 
> wrote:
>
> > Hey folks.
> >
> > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > brought up the issue of moving away from #include guards and towards
> > `#pragma once`.
> >
> > As this has been brought up before, I will be brief: we think it's
> > revisiting because the primary objection in previous threads appears
> > to be that, though `#pragma once` is a cleaner solution to the
> > multiple-include problem, it's not so much better that it's worth the
> > code churn. However, the ongoing Windows integration work means we
> > have to touch these files anyway, so if we agree this is cleaner and
> > desirable, then this is an opportunity to obtain that additional code
> > clarity, without the cost of the churn.
> >
> > For the remainder of the email, I will summarize the history of our
> > discussion of this issue, who will do the work, and what the next
> > steps are.
> >
> > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > #include guards; for existing files, we propose that you change
> > #include guards when you touch them.
> >
> > HISTORY: This has been discussed before, most recently a year ago on
> > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > review[4] that changes style guide's recommendation on the matter.
> >
> > SUMMARIZED OBJECTIONS:
> > 1. The Google style guide explicitly forbids `#pragma once`.
> > 2. This results in a lot of code churn, but is only marginally better.
> > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > doesn't support it.
> > 4. Popular projects like Chrome don't do `#pragma once` because of
> > history clutter.
> > 5. Intermediate state of inconsistency as we transition to `#pragma
> > once` from #include guards.
> >
> > OUR RESPONSE:
> > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > points out in a previous thread that the Google style guide was
> > canonized when `#pragma once` was Windows-only, and the guidance has
> > not changed since because of the history churn problem. As noted
> > above, we think the history churn problem is minimized by the fact
> > that it can be wrapped up into the Windows integration work.
> >
> > For objection (3), the consensus seems to be that the vast majority of
> > compilers we care about (in particular, the ones supporting C++ 11) do
> > support it.
> >
> > For objection (5) we believe the inconsistent state is likely to not
> > be long lived, as long as we commit to wrapping this work up into the
> > Windows integration work.
> >
> > SUMMARIZED ADVANTAGES:
> > * Basically fool-proof. Communicates simply what its function is (you
> > include this file once). Semantically it is "the right tool for the
> > job".
> > * No need for namespacing conventions for #include guards.
> > * No conflicts with reserved identifiers[5].
> > * No internal conflicts between include guards in Stout, Process
> > library, and Mesos (this is one reason we need the namespacing
> > conventions)
> > * Reduces preprocessor definition clutter (we should rely on #define
> > as little as humanly possible).
> > * Optimized to be easy to read and reason about.
> >
> > NEXT STEPS:
> > If we agree that this is the right thing to do, committers would ask
> > people to use `#pragma once` for new code when presented in code
> > reviews. For files that exist, I will take point on transitioning as
> > we complete the Windows integration work. I expect this work to
> > completely land before the new year.
> >
> >
> > Thanks,
> >
> >
> > [1] https://reviews.apache.org/r/39803/
> > [2] https://www.marc.info/?t=142540100400015=1=2
> > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > [4] https://reviews.apache.org/r/30100/
> > [5]
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
> >
>

Re: Welcome Kapil as Mesos committer and PMC member!

[Kapil Arya]

Thanks everyone! :-).



On Thu, Nov 5, 2015 at 3:50 PM, Elizabeth Lingg <elizab...@mesosphere.io>
wrote:

> Congrats Professor! You definitely deserve it.
>
> -Elizabeth
>
> On Thu, Nov 5, 2015 at 10:53 AM, Jie Yu <yujie@gmail.com> wrote:
>
> > Congrats Kapil!
> >
> > On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff <toensh...@me.com> wrote:
> >
> > > I'm happy to announce that Kapil Arya has been voted a Mesos committer
> > and
> > > PMC member!
> > >
> > > Welcome Kapil, and thanks for all of your great contributions to the
> > > project so far!
> > >
> > > Looking forward to lots more of your contributions!
> > >
> > > Thanks
> > > Till
> >
>

Re: Backticks in comments

[Kapil Arya]

+1 for backticks. Also allows us to differentiate ordinary string literals
like names, etc., from code.

On Mon, Nov 2, 2015 at 2:18 PM, Marco Massenzio  wrote:

> +1
>
> I much favor using backticks everywhere for consistency, since (as you
> correctly pointed out) our Doxygen style requires that.
> Hopefully, over time, we will have the whole codebase consistent again
> (also an invite to folks, if you touch the code, to update comments
> accordingly).
>
> BTW - unfortunately, Jira's markdown does not support backticks IIRC, but
> {{ }} to demarcate 'fixed font' in paragraphs (and {code} or {noformat}
> blocks for code snippets).
>
> (RB uses "generally-accepted" markdown, though, so that's good!)
>
> Thanks for raising awareness about this, Greg!
>
> --
> *Marco Massenzio*
> Distributed Systems Engineer
> http://codetrips.com
>
> On Mon, Nov 2, 2015 at 10:38 AM, Alex Clemmer  >
> wrote:
>
> > +1. Additional note is that this is now the de facto syntax for code
> > snippets on the rest of our tools, too, including RB and JIRA.
> >
> > On Mon, Nov 2, 2015 at 10:32 AM, Greg Mann  wrote:
> > > Hey folks!
> > > I wanted to bring up a style issue that I noticed recently. In some
> > > comments in the codebase, backticks are used to quote code excerpts and
> > > object names, while in other comments, single quotes are used. This
> > doesn't
> > > seem to be documented in our style guide (nor in Google's), and I think
> > it
> > > would be a good idea to establish a policy on this and document it, so
> > that
> > > we can avoid wasted review cycles related to this in the future.
> > >
> > > It's likely that the backtick convention began because Doxygen will
> > render
> > > backtick-enclosed text in monospace, and for this reason I would
> propose
> > > that we consistently use backticks to quote code excerpts and object
> > names
> > > in comments from now on. What does everyone else think?
> > >
> > > Cheers,
> > > Greg
> >
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
> >
>

Re: Community Sync Interval

[Kapil Arya]

+1 for bi-weekly.

On Thu, Oct 15, 2015 at 4:40 PM, Jan Schlicht  wrote:

> +1 for weekly.
>
> On Thu, Oct 15, 2015 at 1:36 PM, Artem Harutyunyan 
> wrote:
>
> > +1 for weekly.
> >
> > On Thu, Oct 15, 2015 at 10:41 AM, haosdent  wrote:
> > > +1 for bi-weekly
> > >
> > > On Fri, Oct 16, 2015 at 1:19 AM, Michael Park 
> wrote:
> > >
> > >> We discussed whether the community syncs should be weekly or bi-weekly
> > >> (once every 2 weeks).
> > >>
> > >> There were differing opinions on the subject during the community sync
> > >> today.
> > >>
> > >> An argument for weekly: meetings can be shorter and missing a meeting
> > won't
> > >> be as big a deal as missing a longer meeting.
> > >>
> > >> An argument for bi-weekly: there are many people involved in these
> > >> meetings, we should keep it infrequent so that it reduces people's
> time
> > >> commitments.
> > >>
> > >> This email is intended to capture your +1s or other ideas you might
> > have!
> > >>
> > >> Thanks,
> > >>
> > >> MPark.
> > >>
> > >
> > >
> > >
> > > --
> > > Best Regards,
> > > Haosdent Huang
> >
>
>
>
> --
> *Jan Schlicht*
> Distributed Systems Engineer, Mesosphere
>

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

[Kapil Arya]

+1 (non-binding)

On Sat, Oct 10, 2015 at 9:58 AM, Joris Van Remoortere 
wrote:

> +1 (binding)
>
> On Fri, Oct 9, 2015 at 5:36 PM, Niklas Nielsen 
> wrote:
>
> > Hi all,
> >
> > Following up with an RC with the build fix suggested by Kapil:
> >
> > Please vote on releasing the following candidate as Apache Mesos 0.25.0.
> >
> >
> >
> > 0.25.0 includes the following:
> >
> >
> >
> 
> >
> >  * [MESOS-1474] - Experimental support for maintenance primitives.
> >
> >  * [MESOS-2600] - Added master endpoints /reserve and /unreserve for
> > dynamic reservations.
> >
> >  * [MESOS-2044] - Extended Module APIs to enable IP per container
> > assignment, isolation and resolution.
> >
> >
> > ** Bug fixes
> >
> >   * [MESOS-2635] - Web UI Display Bug when starting lots of tasks with
> > small cpu value.
> >
> >   * [MESOS-2986] - Docker version output is not compatible with Mesos.
> >
> >   * [MESOS-3046] - Stout's UUID re-seeds a new random generator during
> > each call to UUID::random.
> >
> >   * [MESOS-3051] - performance issues with port ranges comparison.
> >
> >   * [MESOS-3052] - Allocator performance issue when using a large number
> > of filters.
> >
> >   * [MESOS-3136] - COMMAND health checks with Marathon 0.10.0 are broken.
> >
> >   * [MESOS-3169] - FrameworkInfo should only be updated if the
> > re-registration is valid.
> >
> >   * [MESOS-3185] - Refactor Subprocess logic in linux/perf.cpp to use
> > common subroutine.
> >
> >   * [MESOS-3239] - Refactor master HTTP endpoints help messages such that
> > they cannot be out of sync.
> >
> >   * [MESOS-3245] - The comments of DRFSorter::dirty is not correct.
> >
> >   * [MESOS-3254] - Cgroup CHECK fails test harness.
> >
> >   * [MESOS-3258] - Remove Frameworkinfo capabilities on re-registration.
> >
> >   * [MESOS-3261] - Move QoS plug-ins to a specified folder like
> > resource_estimator.
> >
> >   * [MESOS-3269] - The comments of Master::updateSlave() is not correct.
> >
> >   * [MESOS-3282] - Web UI no longer shows Tasks information.
> >
> >   * [MESOS-3344] - Add more comments for strings::internal::fmt.
> >
> >   * [MESOS-3351] - duplicated slave id in master after master failover.
> >
> >   * [MESOS-3387] - Refactor MesosContainerizer to accept namespace
> > dynamically.
> >
> >   * [MESOS-3408] - Labels field of FrameworkInfo should be added into v1
> > mesos.proto.
> >
> >   * [MESOS-3411] - ReservationEndpointsTest.AvailableResources appears to
> > be faulty.
> >
> >   * [MESOS-3423] - Perf event isolator stops performing sampling if a
> > single timeout occurs.
> >
> >   * [MESOS-3426] - process::collect and process::await do not perform
> > discard propagation.
> >
> >   * [MESOS-3430] -
> > LinuxFilesystemIsolatorTest.ROOT_PersistentVolumeWithoutRootFilesystem
> > fails on CentOS 7.1.
> >
> >   * [MESOS-3450] - Update Mesos C++ Style Guide for namespace usage.
> >
> >   * [MESOS-3451] - Failing tests after changes to
> > Isolator/MesosContainerizer API.
> >
> >   * [MESOS-3458] - Segfault when accepting or declining inverse offers.
> >
> >   * [MESOS-3474] - ExamplesTest.{TestFramework, JavaFramework,
> > PythonFramework} failed on CentOS 6.
> >
> >   * [MESOS-3489] - Add support for exposing Accept/Decline responses for
> > inverse offers.
> >
> >   * [MESOS-3490] - Mesos UI fails to represent JSON entities.
> >
> >   * [MESOS-3512] - Don't retry close() on EINTR.
> >
> >   * [MESOS-3513] - Cgroups Test Filters aborts tests on Centos 6.6.
> >
> >   * [MESOS-3519] - Fix file descriptor leakage / double close in the code
> > base.
> >
> >   * [MESOS-3538] -
> > CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy
> test
> > is flaky.
> >
> >   * [MESOS-3575] - V1 API java/python protos are not generated.
> >
> >
> > ** Improvements
> >
> >   * [MESOS-2719] - Deprecating '.json' extension in master endpoints
> urls.
> >
> >   * [MESOS-2757] - Add -> operator for Option, Try, Result,
> > Future.
> >
> >   * [MESOS-2875] - Add containerId to ResourceUsage to enable QoS
> > controller to target a container.
> >
> >   * [MESOS-2964] - libprocess io does not support peek().
> >
> >   * [MESOS-2983] - Deprecating '.json' extension in slave endpoints url.
> >
> >   * [MESOS-2984] - Deprecating '.json' extension in files endpoints url.
> >
> >   * [MESOS-3037] - Add a SUPPRESS call to the scheduler.
> >
> >   * [MESOS-3187] - Docker cli option support.
> >
> >   * [MESOS-3304] - Remove remnants of LIBPROCESS_STATISTICS_WINDOW.
> >
> >   * [MESOS-3312] - Factor out JSON to repeated protobuf conversion.
> >
> >   * [MESOS-3340] - Command-line flags should take precedence over OS Env
> > variables.
> >
> >   * [MESOS-3347] - Remove dead code in src/linux/perf.cpp.
> >
> >   * [MESOS-3377] - mesos docker container with container_name as ENV
> > variable.
> >
> >   * [MESOS-3457] - Add flag to disable hostname 

Re: custom(ized) conteinerization

[Kapil Arya]

On Sat, Oct 10, 2015 at 2:38 AM, Timothy Chen  wrote:

> As Ben said containierizers don't conflict since the framework specifies
> which containerizer the task should be launched from.
>
> And isolators are not configurable per task but per slave, so all tasks
> will use the same isolators in the same slave.
>

There is a Jira (MESOS-3361
) to allow slaves to
pick/enable Isolators per-task. That in combination with isolator
capabilities (MESOS-3362 )
can help the framework to specify custom isolators.

Alternatively, as Ben suggested, one can write a custom network-isolator
that looks at TaskInfo/ExecutorInfo to decide what "kind" of
network-isolation to enable for the current task.



> Tim
>
> > On Oct 9, 2015, at 11:22 PM, Alex Glikson  wrote:
> >
> > Thanks!
> >
> >> You can mix containerizers, although they should not conflict with each
> >> other.
> >
> > How would I know whether they conflict? For example, the docker one and
> > the default mesos one with certain configuration of isolators etc?
> >
> > Thanks,
> > Alex
> >
> >
> > Benjamin Mahler  wrote on 10/10/2015 03:51:56
> > AM:
> >
> >> From: Benjamin Mahler 
> >> To: dev 
> >> Date: 10/10/2015 03:52 AM
> >> Subject: Re: custom(ized) conteinerization
> >>
> >> (1) is something that has come up before. The containerizer deals with a
> >> variable sized container, the semantics of a task are defined by the
> >> executor, there is no way for the containerizer to understand the
> > meaning
> >> of a task currently. Some tasks are "special" in that they don't have an
> >> executor (e.g. command task, docker task, etc), and in this case they
> > will
> >> be isolated individually. The main approach that has been discussed to
> > my
> >> knowledge is to have the executor leverage the mesos containerizer to
> >> create nested containers:
> > https://issues.apache.org/jira/browse/MESOS-
> >>
> >> For (2) you should implement a custom network _isolator_ that the mesos
> >> containerizer can use.
> >>
> >> With respect to (3), for regular resources the policy used in Mesos is
> > that
> >> Mesos will never make decisions to kill things, it must be triggered by
> > the
> >> framework or an operator. So this requirement should be met already. For
> >> revocable resources, Mesos may destroy containers, but the framework
> > will
> >> be aware of that when deciding to use them. If they are stateful, you
> >> should use reservations and store the data in a volume.
> >>
> >> You can mix containerizers, although they should not conflict with each
> >> other.
> >>
> >>> On Fri, Oct 9, 2015 at 3:04 AM, Alex Glikson 
> wrote:
> >>>
> >>> Triggered by the thread on potential deprecation of external
> >>> containerizer, I wonder what would make sense to do to address the
> >>> following set of requirements:
> >>> 1. I need resource isolation for individual tasks (mainly for QoS
> >>> reasons), so having container per task seems reasonable
> >>> 2. I have rather advanced networking requirements, not easily
> > addressable
> >>> with default mesos containerizer or docker
> >>> 3. Some of the tasks are stateful, so I would really prefer that Mesos
> >>> doesn't kill them, pretty much ever (unless triggered by the
> > framework)
> >>>
> >>> It seems that having my own containerizer would be a reasonable
> > approach.
> >>> But given some of the requirements above, I am trying to figure out
> >>> whether I would at all need to implement "usage" and "update" (and
> > maybe
> >>> even 'destroy', unless it is invoked as part of killTask received from
> > the
> >>> framework?).
> >>>
> >>> Moreover, the isolation mechanism I have in mind does use the same
> > Linux
> >>> features as docker/mesos containerizers (cgroups, namespaces, etc),
> > but in
> >>> a somewhat different manner. So, I wonder whether I can use more than
> > one
> >>> containerizer on the same host -- e.g., to run tasks of my framework
> > on
> >>> the same host as tasks of , say, Marathon+docker (and if yes, how can
> > I
> >>> check whether they will work together). If mixing containerizers in
> > the
> >>> same host is not recommended, is there an easy way to dynamically
> > decide
> >>> which slaves are 'allocated' to which 'type' of resources (e.g., some
> > sort
> >>> of entire-host allocation policy)?
> >>>
> >>> Some thoughts/advice would be really helpful, before we actually spend
> >>> time implementing a new containerizer, one way or another.
> >>>
> >>> Thanks!
> >>> Alex
> >>>
> >>> P.S. Disclaimer: I am new to Mesos, so maybe some (or all) of the
> > above
> >>> doesn't make much sense, so bear with me..
> >
> >
>

Re: Proposal: moving Mesos website to project codebase

[Kapil Arya]

+1

On Fri, Oct 9, 2015 at 1:02 PM, Niklas Nielsen  wrote:

> +1
>
> On 9 October 2015 at 09:50, Yan Xu  wrote:
>
> > +1 for making it easier for contributors to understand the website code
> and
> > collaboratively maintain it!
> >
> > --
> > Jiang Yan Xu  @xujyan 
> >
> > On Fri, Oct 9, 2015 at 5:21 PM, Paul Brett 
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Oct 9, 2015 at 8:59 AM, haosdent  wrote:
> > >
> > > > +1!
> > > > On Oct 9, 2015 10:37 PM, "Kevin Sweeney"  wrote:
> > > >
> > > > > +1!
> > > > >
> > > > > On Fri, Oct 9, 2015 at 3:35 PM Marco Massenzio <
> ma...@mesosphere.io>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > Dave - great stuff!
> > > > > >
> > > > > > *Marco Massenzio*
> > > > > >
> > > > > > *Distributed Systems Engineerhttp://codetrips.com <
> > > > http://codetrips.com
> > > > > >*
> > > > > >
> > > > > > On Fri, Oct 9, 2015 at 3:05 PM, Dave Lester  >
> > > > wrote:
> > > > > >
> > > > > > > As part of the #MesosCon Europe hackathon, my team has been
> > making
> > > > > > > improvements to the website. Among these changes, we'd like to
> > > > propose
> > > > > > > changing where the website source files live by moving them to
> > the
> > > > main
> > > > > > > Mesos codebase. Our current progress / working branch of this
> is
> > > > > > > available on GitHub:
> > > https://github.com/fayusohenson/mesos/tree/site
> > > > > > >
> > > > > > > * What does this mean? *
> > > > > > > We've added a /site directory to the Mesos codebase, which
> > includes
> > > > the
> > > > > > > website source files. Today, these live in subversion. The rake
> > > file
> > > > > and
> > > > > > > other parts of building the website all work in this new
> > > environment,
> > > > > > > plus a number of related fixes (image linking, etc).
> > > > > > >
> > > > > > > For committers that are familiar with the current model for
> > pushing
> > > > the
> > > > > > > site live, this immediate change still requires us `svn commit`
> > the
> > > > > > > /publish directory for the website (static files that are
> > > generated).
> > > > > > >
> > > > > > > * Why this change? *
> > > > > > > 1. Today we do not have an easy process for the community to
> > > > contribute
> > > > > > > to the project website. By merging this with the Mesos
> codebase,
> > it
> > > > > will
> > > > > > > be significantly easier to send a review or pull request.
> > > > > > > 2. It'll be easier for committers to manage the website, and
> > check
> > > > that
> > > > > > > documentation changes render on the website properly before
> > > > committing.
> > > > > > > Because it's difficult to do today, this is often not checked.
> :(
> > > > > > > 3. It's a solid step toward an automated deployment of the
> > website
> > > in
> > > > > > > the future: https://issues.apache.org/jira/browse/MESOS-1309
> > > > > > >
> > > > > > > * Who approves of this change? *
> > > > > > > As the Mesos website maintainer, I feel good about this change
> > and
> > > > its
> > > > > > > direction for the project. Before committing this change, I'd
> > like
> > > > > > > community support that including this in the main Mesos
> codebase
> > > > makes
> > > > > > > sense.
> > > > > > >
> > > > > > > Comments? Questions?
> > > > > > >
> > > > > > > Dave
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > @paul_b
> > >
> >
>

Re: Removing external containerizer from code base

[Kapil Arya]

On Thu, Oct 8, 2015 at 1:57 PM, Jie Yu  wrote:

> Alex,
>
> Implementing your own containerizer totally makes sense. The containerizer
> interface can be modulized and your own containerizer can be implemented as
> a module. Please take a look at the module documentation
> . From what I
> can tell, implementing your own containerizer as a module will definitely
> be simpler than an external solution.
>
>  I assume we would have to implement it in cpp,
>
>
> Most likely because that's the most straightforward way. Other languages
> are also possible (e.g., using JNI for Java).
>

I don't know all the details, but I guess, depending upon the exact
interface, it might be possible to have a C++ wrapper around a non-C++
containerizer module. In a very naive approach, one simply fork/execs the
"external" non-C++ containerizer script/program.


>
> it might require recompiling (parts of) Mesos, some other things?
>
>
> No. With modules, you don't have to.
>
> Let me know if you have any further questions!
>
> - Jie
>
> On Thu, Oct 8, 2015 at 10:44 AM, Alex Glikson  wrote:
>
> > Actually we have been thinking to implement our own containerizer, and
> the
> > option to use ECP seemed attractive.
> > Can you, please, elaborate on the implications of having our own
> > containerizer without ECP? I assume we would have to implement it in cpp,
> > it might require recompiling (parts of) Mesos, some other things?
> >
> > Thanks,
> > Alex
> >
> >
> >
> >
> > From:Jie Yu 
> > To:mesos , "u...@mesos.apache.org" <
> > u...@mesos.apache.org>
> > Date:08/10/2015 03:12 AM
> > Subject:Removing external containerizer from code base
> > --
> >
> >
> >
> > Hey guys,
> >
> > Per discussion in MESOS-3370
> > , I'll start removing
> > the
> > external containerizer and cleaning up the relevant code.
> >
> > Please let me know if you have any concern. Thanks!
> >
> > - Jie
> >
> >
> >
>

Re: Removing external containerizer from code base

[Kapil Arya]

On Thu, Oct 8, 2015 at 2:19 PM, Jie Yu  wrote:

> Alex,
>
> but I don't see 'containerizer' as one of the supported module types listed
> > in the documentation.. Can you, please, clarify?
>
>
> Not right now, but should be very trivial to do. Kapil or I can definitely
> help with this.
>

+1


>
> - Jie
>
> On Thu, Oct 8, 2015 at 11:15 AM, Alex Glikson  wrote:
>
> > Thanks Jie, this sounds promising, but I don't see 'containerizer' as one
> > of the supported module types listed in the documentation..
> > Can you, please, clarify?
> >
> > Thanks,
> > Alex
> >
> >
> >
> >
> > From:   Jie Yu 
> > To: u...@mesos.apache.org
> > Cc: dev 
> > Date:   08/10/2015 08:57 PM
> > Subject:Re: Removing external containerizer from code base
> >
> >
> >
> > Alex,
> >
> > Implementing your own containerizer totally makes sense. The
> containerizer
> > interface can be modulized and your own containerizer can be implemented
> > as
> > a module. Please take a look at the module documentation
> > . From
> what I
> > can tell, implementing your own containerizer as a module will definitely
> > be simpler than an external solution.
> >
> >  I assume we would have to implement it in cpp,
> >
> >
> > Most likely because that's the most straightforward way. Other languages
> > are also possible (e.g., using JNI for Java).
> >
> > it might require recompiling (parts of) Mesos, some other things?
> >
> >
> > No. With modules, you don't have to.
> >
> > Let me know if you have any further questions!
> >
> > - Jie
> >
> > On Thu, Oct 8, 2015 at 10:44 AM, Alex Glikson 
> wrote:
> >
> > > Actually we have been thinking to implement our own containerizer, and
> > the
> > > option to use ECP seemed attractive.
> > > Can you, please, elaborate on the implications of having our own
> > > containerizer without ECP? I assume we would have to implement it in
> > cpp,
> > > it might require recompiling (parts of) Mesos, some other things?
> > >
> > > Thanks,
> > > Alex
> > >
> > >
> > >
> > >
> > > From:Jie Yu 
> > > To:mesos , "u...@mesos.apache.org" <
> > > u...@mesos.apache.org>
> > > Date:08/10/2015 03:12 AM
> > > Subject:Removing external containerizer from code base
> > > --
> > >
> > >
> > >
> > > Hey guys,
> > >
> > > Per discussion in MESOS-3370
> > > , I'll start
> removing
> > > the
> > > external containerizer and cleaning up the relevant code.
> > >
> > > Please let me know if you have any concern. Thanks!
> > >
> > > - Jie
> > >
> > >
> > >
> >
> >
> >
> >
>

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

[Kapil Arya]

-1 (non-binding)

Compilation fails on OpenSUSE Tumbleweed (Linux 4.1.6, gcc 5.1.1, glibc
2.22) with the following errors:
[Created Issue: https://issues.apache.org/jira/browse/MESOS-3603]


In file included from ../../src/tests/values_tests.cpp:22:0:
../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h: In
instantiatio
n of ‘testing::AssertionResult testing::internal::CmpHelperEQ(const char*,
const char*,
const T1&, const T2&) [with T1 = int; T2 = long unsigned int]’:
../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h:1484:23:
  requi
red from ‘static testing::AssertionResult
testing::internal::EqHelper::Compare(const char*, const char*, const T1&, const T2&) [with T1 = int;
T2 = long un
signed int; bool lhs_is_null_literal = false]’
../../src/tests/values_tests.cpp:287:3:   required from here
../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h:1448:16:
error:
comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
  if (expected == actual) {
   ^
 CXX  tests/containerizer/mesos_tests-provisioner_docker_tests.o
^CMakefile:6779: recipe for target 'tests/mesos_tests-values_tests.o' failed
make[3]: *** [tests/mesos_tests-values_tests.o] Interrupt

===

System details:

$ uname -a
Linux thinkpad 4.1.6-3-desktop #1 SMP PREEMPT Fri Aug 28 10:59:34 UTC 2015
(d867e86) x86_64 x86_64 x86_64 GNU/Linux

$ gcc --version
gcc (SUSE Linux) 5.1.1 20150713 [gcc-5-branch revision 225736]
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.22 (git bbab82c25da9), by
Roland McGrath et al.
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for x86_64-suse-linux.
Compiled by GNU CC version 5.1.1 20150713 [gcc-5-branch revision 225736].
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
.

$ cat /etc/SuSE-release
openSUSE 20150909 (x86_64)
VERSION = 20150909
CODENAME = Tumbleweed
# /etc/SuSE-release is deprecated and will be removed in the future, use
/etc/os-release instead



On Wed, Oct 7, 2015 at 6:14 PM, Greg Mann  wrote:

> Successfully built `sudo make distcheck` on CentOS 7.1 and Ubuntu 14.04
> with only expected test failures. On our Fedora 22 CI build, however, while
> the tests are building the following compile-time error is produced:
>
> [17:18:46][Step 4/6]   CXX
>  tests/containerizer/mesos_tests-composing_containerizer_tests.o
>
> [17:18:48][Step 4/6] In file included from
> ../../../src/tests/values_tests.cpp:22:0:
>
> [17:18:48][Step 4/6]
> ../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h: In
> instantiation of ‘testing::AssertionResult
> testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const
> T2&) [with T1 = int; T2 = long unsigned int]’:
>
> [17:18:48][Step 4/6]
>
> ../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h:1484:23:
>   required from ‘static testing::AssertionResult
> testing::internal::EqHelper::Compare(const char*,
> const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int;
> bool lhs_is_null_literal = false]’
>
> [17:18:48][Step 4/6] ../../../src/tests/values_tests.cpp:149:3:   required
> from here
>
> [17:18:48][Step 4/6]
>
> ../3rdparty/libprocess/3rdparty/gmock-1.7.0/gtest/include/gtest/gtest.h:1448:16:
> error: comparison between signed and unsigned integer expressions
> [-Werror=sign-compare]
>
> [17:18:48][Step 4/6]if (expected == actual) {
>
> [17:18:48][Step 4/6] ^
>
>
> Cherry-picking one commit (bfeb070a2aef52f445e "Fixed compiler warning in
> values test.") resolves this issue.
>
>
>
> On Wed, Oct 7, 2015 at 2:32 AM, Joris Van Remoortere 
> wrote:
>
> > +1 (binding)
> >
> > On Mon, Oct 5, 2015 at 11:12 PM, Niklas Nielsen 
> > wrote:
> >
> >> Hi all,
> >>
> >> Please vote on releasing the following candidate as Apache Mesos 0.25.0.
> >>
> >>
> >>
> >> 0.25.0 includes the following:
> >>
> >>
> >>
> 
> >>
> >>  * [MESOS-1474] - Experimental support for maintenance primitives.
> >>
> >>  * [MESOS-2600] - Added master endpoints /reserve and /unreserve for
> >> dynamic reservations.
> >>
> >>  * [MESOS-2044] - Extended Module APIs to enable IP per container
> >> assignment, isolation and resolution.
> >>
> >>
> >> ** Bug fixes
> 

Re: Failed to build Mesos module

[Kapil Arya]

On Wed, Sep 23, 2015 at 1:42 AM, zhiwei <zhiw...@gmail.com> wrote:

> Hi Kapil,
>
> I don't know how to contribute to modules project, but there are two
> issues:
>

One possibility is to simply create a pull request on github :-).


>
> My testing machine is Ubuntu 14.04 amd64.
>
> *1. Mesos lib64 dir*
>
> https://github.com/mesos/modules/blob/master/config ure.ac#L39
> <https://github.com/mesos/modules/blob/master/configure.ac#L39>
>
> MESOS_LDFLAGS="-L${mesos}/lib64 -lmesos -lglog -lprotobuf"
>
> Mesos installs the libraries(*.so) to $prefix/lib directory by default, not
> $prefix/lib64.
>

I guess we need to test for both $prefix/lib and $prefix/lib64 and choose
appropriately.


>
>
> *2. picojson.h header file*
>
> I workaround this issue to insert a line:
>
> https://github.com/mesos/modules/blob/master/configure.ac#L55
>
> if test -d "$mesos_build_dir"; then
> cp $mesos_build_dir/3rdparty/libprocess/3rdparty/picojson-*/picojson.h
> $mesos_build_dir/include
>

This wouldn't work if we didn't have mesos sources. A possibility is to
include the picojson header directly into the sources or add a submodule to
the repo that points to the picojson repo.


>
>
> Thanks.
>
> On Fri, Sep 18, 2015 at 2:15 PM, Qian AZ Zhang <zhang...@cn.ibm.com>
> wrote:
>
> > Hi Kapil,
> >
> > Any updates? :-)
> >
> > I have resolved that issue with a workaround by using the option
> > "--disable-java", like:
> > ../configure --with-glog=/usr --with-protobuf=/usr --with-boost=/usr
> > --disable-java
> > And then I did "make" and "make install" successfully.
> >
> > However, after I cloned the code from https://github.com/mesos/modules
> and
> > found an error to build it:
> > $ ../configure --with-mesos=/usr/local
> > checking for gcc... gcc
> > checking whether the C compiler works... yes
> > ...
> > checking for google/protobuf/message.h... yes
> > checking picojson.h usability... no
> > checking picojson.h presence... no
> > checking for picojson.h... no
> > configure: error: picojson is not installed.
> >
> > So it can not find picojson.h. And I checked the source code tree of
> > Mesos, and found picojson as a 3rd party lib are here:
> > mesos/3rdparty/libprocess/3rdparty/picojson-4f93734.tar.gz, maybe we
> should
> > put the picojson.h to /usr/local/include during "make install"?
> >
> >
> > Regards,
> > Qian Zhang
> >
> > [image: Inactive hide details for Kapil Arya ---09/18/2015
> 00:34:08---I'll
> > take a look shortly and will report back with the status. Ka]Kapil Arya
> > ---09/18/2015 00:34:08---I'll take a look shortly and will report back
> with
> > the status. Kapil
> >
> > From: Kapil Arya <ka...@mesosphere.io>
> > To: dev <dev@mesos.apache.org>
> > Date: 09/18/2015 00:34
> > Subject: Re: Failed to build Mesos module
> > --
> >
> >
> >
> > I'll take a look shortly and will report back with the status.
> >
> > Kapil
> >
> >
> > On Thu, Sep 17, 2015 at 10:56 AM, Qian AZ Zhang <zhang...@cn.ibm.com>
> > wrote:
> >
> > > Thanks Kapil.
> > >
> > > I am now following the steps in https://github.com/mesos/modules to
> > build
> > > my module, but it failed:
> > > stack@u1404u1:~/mesos/build$ ../configure --with-glog=/usr/local
> > > --with-protobuf=/usr/local --with-boost=/usr/local
> > > checking build system type... x86_64-unknown-linux-gnu
> > > checking host system type... x86_64-unknown-linux-gnu
> > > checking target system type... x86_64-unknown-linux-gnu
> > > ...
> > > checking for /usr/share/java/protobuf.jar... no
> > > configure: error: cannot find PROTOBUF_JAR=/usr/share/java/protobuf.jar
> > >
> > > And I have already installed protobuf, glog and boost libraries in my
> > > machine with the command:
> > > sudo apt-get install libprotobuf-dev libboost-dev libgoogle-glog-dev
> > >
> > > Can you please help? Thanks!
> > >
> > >
> > > Regards,
> > > Qian Zhang
> > >
> > > [image: Inactive hide details for Kapil Arya ---09/17/2015
> > > 21:50:55---Hello Qian, Please follow the instructions on
> > > https://github.com/]Kapil Arya ---09/17/2015 21:50:55---Hello Qian,
> > > Please follow the instructions on https://github.com/mesos/modules to
> > get
> > >
> 

Re: Failed to build Mesos module

[Kapil Arya]

Hello Qian,

Please follow the instructions on https://github.com/mesos/modules to get
up and running with building a mesos module. Apparently, building mesos
modules requires you to build Mesos without bundled protobuf, glog and
boost libraries. Thus, you need to have them installed system wide. The
above repo has a readme and a few test modules that you can play with.

Please let us know if you need any more help.

Kapil

On Thu, Sep 17, 2015 at 9:20 AM, Qian AZ Zhang  wrote:

>
>
> Hi all,
>
> I am trying to follow the doc (
>
> https://github.com/apache/mesos/blob/master/docs/modules.md#writing-mesos-modules
> ) to implement a test module, but when I built the module, I got the
> following error:
> user1@test1:~/mesos/src/examples$ g++ -lmesos -fpic -o test_module.o
> test_module.cpp
> In file included from /usr/local/include/mesos/mesos.hpp:22:0,
>  from test_module.hpp:22,
>  from test_module.cpp:2:
> /usr/local/include/mesos/mesos.pb.h:9:42: fatal error:
> google/protobuf/stubs/common.h: No such file or directory
>  #include 
> ^
> compilation terminated.
>
> It seems it can not find the header file: google/protobuf/stubs/common.h. I
> see this header file is in the Mesos source code tree, but not in
> /usr/local/include/mesos ( I have done "make install" after building Mesos
> source code).
>
> Any help will be appreciated, thanks!
>
>
> Regards,
> Qian Zhang

Re: [Mesos][Patch] How to make the patches under review board link to a mesos bug

[Kapil Arya]

You need to click on the pencil icon near Bugs: and type in the Jira
ticket number, e.g. MESOS-1234. You can do this only if you are logged in
into Reviewboard and have created the review request yourself.

Kapil

PS: The dev list doesn't allow images, so if you had attached any, they
were discarded :-).

On Wed, Aug 5, 2015 at 5:52 PM, Guangya Liu gyliu...@gmail.com wrote:

 Hi Mesos,

 I see that there are some patches can be easily be directed to a mesos bug
 by a link on the right side of the review board, how can I have this for my
 patch?
 ​

 Thanks,

 Guangya

Re: Update minimum required automake version to 1.13

[Kapil Arya]

In order to better evaluate the current position of developers with respect
to autotools versions, is there a way we can do an informal poll to see how
many people are still using automake 1.11 or 1.12? If it's only a small
number of people, we can try to find an upgrade path for their
system/distro to upgrade automake. Is this a reasonable things to do/ask
for?

Kapil

On Fri, Jun 26, 2015 at 4:24 PM, James Peach jor...@gmail.com wrote:


  On Jun 25, 2015, at 11:01 PM, Kapil Arya ka...@mesosphere.io wrote:
 
  On Fri, Jun 26, 2015 at 1:38 AM, Benjamin Mahler 
 benjamin.mah...@gmail.com
  wrote:
 
  Taking a step back, it looks like the patches in MESOS-2273 approached
 the
  problem assuming 1.13. Have you re-considered how you might approach it
 if
  you didn't have 1.13? Or is this 1.13 macro the only solution?
 
 
  Hmm, I went back to take another quick look at the situation and here is
 my
  conclusion. The automake recursive targets makes the life somewhat easier
  (and make the code less hackish) by taking care of recursive invocation
 of
  the tests target for the subdirs. If we didn't have this new macro, the
  approach would have been to add a tests target by hand to the
 appropriate
  Makefile.am files (top-level, src/,  3rdparty/, and 3rdparty/libprocess).
  This is what we have been doing for stuff like maven-install and
 bench
  targets. So, if we were to go for the upgrade path, we might consider
  rewriting some of these existing targets as well.

 Maybe I'm jumping in the middle without the full context, but why don't
 you just always build the tests? The way I have done this in other project
 is to always build the tests with noinst_ automake variables. Them make
 check will just depend on tests that are already built.

 You can then add a --enable-test-suite option to configure to cause the
 tests to be installed. This would be pretty useful since you could easily
 build a mesos-tests package for a CI pipeline.

  Worth noting that users can already build the tests without running
 them by
  specifying GTEST_FILTER=, so is the upgrade pain worth it? With gcc
 4.8,
  we had a lot of benefits motivating us :)
 
 
  I do partially agree with you in that with gcc 4.8 we had huge benefits
  compared to what we get with automake 1.13.

 Note that requiring gcc 4.8 affects everyone who build Mesos. Requiring
 more recent autotools mainly affects  developers since autotools is not
 required for building from official source releases.

 J

Re: Update minimum required automake version to 1.13

[Kapil Arya]

On Fri, Jun 26, 2015 at 1:38 AM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 Taking a step back, it looks like the patches in MESOS-2273 approached the
 problem assuming 1.13. Have you re-considered how you might approach it if
 you didn't have 1.13? Or is this 1.13 macro the only solution?


Hmm, I went back to take another quick look at the situation and here is my
conclusion. The automake recursive targets makes the life somewhat easier
(and make the code less hackish) by taking care of recursive invocation of
the tests target for the subdirs. If we didn't have this new macro, the
approach would have been to add a tests target by hand to the appropriate
Makefile.am files (top-level, src/,  3rdparty/, and 3rdparty/libprocess).
This is what we have been doing for stuff like maven-install and bench
targets. So, if we were to go for the upgrade path, we might consider
rewriting some of these existing targets as well.


 Worth noting that users can already build the tests without running them by
 specifying GTEST_FILTER=, so is the upgrade pain worth it? With gcc 4.8,
 we had a lot of benefits motivating us :)


I do partially agree with you in that with gcc 4.8 we had huge benefits
compared to what we get with automake 1.13. Nevertheless, I would like to
quote Cody's comment from the RR in response to Dominic's question that was
along the same lines:

Not much code, there is runtime / developer slow down overhead in
GTEST_FILTER (not documented, build test groups in clusters, just
running the constructors/destructors around the tests takes a bit). I
can also break the GTEST_FILTER setup (I can add a destructor to a
test which will generate SIGSEGV and break a make check
GTEST_FILTER='' even though tests compile).

This should enable parallelizing building all the tests in mesos rather
than doing them in chunks which should make things go quicker when I just
want to verify the tests build. Also makes it easier to seperate automated
builder failure states without relying on undocumented / non-explicit
behavior (compiling core, compiling tests, running tests)


Similar sentiments were expressed by Joris as well, if I remember correctly.

Having said that, if we decide that the automake upgrade path is too much
of a hassle, I would like to take a stab at adding the non-recursive
tests target. It definitely is less hackish than make check
GTEST_FILTER= :-).

Kapil



 On Thu, Jun 25, 2015 at 4:10 PM, Kapil Arya ka...@mesosphere.io wrote:

  Apparently, there is a way to get latest the autotools on CentOS 5
 through
  the same community that provides devtoolset:
  https://www.softwarecollections.org/en/scls/praiskup/autotools/
 
  If the tools are available, would there be any other objections to move
 to
  the newer versions?
 
  On Thu, Jun 25, 2015 at 7:02 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
   Well, CentOS 5 users don't have to upgrade gcc, they can use
  devtoolset-2.
   However, devtoolset-2 doesn't provide the newer automake FWICT.
  
   On Thu, Jun 25, 2015 at 3:38 PM, Marco Massenzio ma...@mesosphere.io
   wrote:
  
On Thu, Jun 25, 2015 at 3:27 PM, Cody Maloney c...@mesosphere.io
   wrote:
   
 CentOS 5 and 6 don't come out of the box with a new enough version
 of
   GCC
 to compile Mesos. Already they need to upgrade that to compile
  Mesos. I
 don't see how adding another upgrade when they have to do GCC is
  overly
 onerous / should require lots of compatibility hacks to make
   unnecessary.

   
+1
Different story for production servers; but build/dev machines are
   supposed
to use modern build/dev tools and environments (unless supporting an
   older
toolchain is a specific need for the project).
   
   

 On Thu, Jun 25, 2015 at 3:17 PM Kapil Arya ka...@mesosphere.io
   wrote:

  It's not available for CentOS 5/6 or the previous debian stable.
 I
guess
  since we still want to keep supporting the older distros, one
possibility
  is to create a patch for configure.ac which is applied during
 ./bootstrap
  after detecting the automake version. Is this an acceptable
  solution?
 
  If this works, then we can decide on whether we want to patch it
  for
 older
  ( 1.13) or newer (= 1.13) automake version. Is there a
 preference
 there?
 
  Kapil
 
  On Thu, Jun 25, 2015 at 2:30 PM, Jake Farrell 
 jfarr...@apache.org
  
 wrote:
 
   we encountered a lot of issues in thrift between all the
  backwards
   incompatible changes automake had in 1.12 to 1.14 and trying to
support
  all
   the default versions across different distros. due to this we
 are
  switching
   to cmake as well
  
   -Jake
  
  
   On Thu, Jun 25, 2015 at 1:46 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com
   wrote:
  
What about CentOS 5 and 6?
https://en.wikipedia.org/wiki/CentOS#End

Update minimum required automake version to 1.13

[Kapil Arya]

Hi All,

First off, I am not sure if we record the minimum required version of
automake/autoconf somewhere in the documentation.

Having said that, I want to propose to move to automake 1.13 in order to be
able to use the AM_EXTRA_RECURSIVE_TARGETS macro which allows us to add a
test target to just build the test and not run it. The issue is tracked
at https://issues.apache.org/jira/browse/MESOS-2273 and the corresponding
RRs have received some ship-its.

Best,
Kapil

==
Compatibility notes:
Automake 1.13 came out in 2013 and here is the compatibility status for
leading distros:
* Debian: Since 8.0 [1].
* Ubuntu: Since 13.10 [2].
* Fedora: Since Fedora 20 [3].
* Centos: Since 7.0 [4].

1. https://packages.debian.org/jessie/automake
2. https://launchpad.net/ubuntu/trusty/+package/automake
3. https://apps.fedoraproject.org/packages/automake
4. http://mirror.centos.org/centos/7/os/x86_64/Packages/

Re: Update minimum required automake version to 1.13

[Kapil Arya]

It's not available for CentOS 5/6 or the previous debian stable. I guess
since we still want to keep supporting the older distros, one possibility
is to create a patch for configure.ac which is applied during ./bootstrap
after detecting the automake version. Is this an acceptable solution?

If this works, then we can decide on whether we want to patch it for older
( 1.13) or newer (= 1.13) automake version. Is there a preference there?

Kapil

On Thu, Jun 25, 2015 at 2:30 PM, Jake Farrell jfarr...@apache.org wrote:

 we encountered a lot of issues in thrift between all the backwards
 incompatible changes automake had in 1.12 to 1.14 and trying to support all
 the default versions across different distros. due to this we are switching
 to cmake as well

 -Jake


 On Thu, Jun 25, 2015 at 1:46 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com
 wrote:

  What about CentOS 5 and 6?
  https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
 
  Also, how does this interact with the effort to use CMake?
  https://issues.apache.org/jira/browse/MESOS-898
 
  On Thu, Jun 25, 2015 at 10:40 AM, Kapil Arya ka...@mesosphere.io
 wrote:
 
   Hi All,
  
   First off, I am not sure if we record the minimum required version of
   automake/autoconf somewhere in the documentation.
  
   Having said that, I want to propose to move to automake 1.13 in order
 to
  be
   able to use the AM_EXTRA_RECURSIVE_TARGETS macro which allows us to
  add a
   test target to just build the test and not run it. The issue is
 tracked
   at https://issues.apache.org/jira/browse/MESOS-2273 and the
  corresponding
   RRs have received some ship-its.
  
   Best,
   Kapil
  
   ==
   Compatibility notes:
   Automake 1.13 came out in 2013 and here is the compatibility status for
   leading distros:
   * Debian: Since 8.0 [1].
   * Ubuntu: Since 13.10 [2].
   * Fedora: Since Fedora 20 [3].
   * Centos: Since 7.0 [4].
  
   1. https://packages.debian.org/jessie/automake
   2. https://launchpad.net/ubuntu/trusty/+package/automake
   3. https://apps.fedoraproject.org/packages/automake
   4. http://mirror.centos.org/centos/7/os/x86_64/Packages/
  
 

Re: Update minimum required automake version to 1.13

[Kapil Arya]

Apparently, there is a way to get latest the autotools on CentOS 5 through
the same community that provides devtoolset:
https://www.softwarecollections.org/en/scls/praiskup/autotools/

If the tools are available, would there be any other objections to move to
the newer versions?

On Thu, Jun 25, 2015 at 7:02 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 Well, CentOS 5 users don't have to upgrade gcc, they can use devtoolset-2.
 However, devtoolset-2 doesn't provide the newer automake FWICT.

 On Thu, Jun 25, 2015 at 3:38 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  On Thu, Jun 25, 2015 at 3:27 PM, Cody Maloney c...@mesosphere.io
 wrote:
 
   CentOS 5 and 6 don't come out of the box with a new enough version of
 GCC
   to compile Mesos. Already they need to upgrade that to compile Mesos. I
   don't see how adding another upgrade when they have to do GCC is overly
   onerous / should require lots of compatibility hacks to make
 unnecessary.
  
 
  +1
  Different story for production servers; but build/dev machines are
 supposed
  to use modern build/dev tools and environments (unless supporting an
 older
  toolchain is a specific need for the project).
 
 
  
   On Thu, Jun 25, 2015 at 3:17 PM Kapil Arya ka...@mesosphere.io
 wrote:
  
It's not available for CentOS 5/6 or the previous debian stable. I
  guess
since we still want to keep supporting the older distros, one
  possibility
is to create a patch for configure.ac which is applied during
   ./bootstrap
after detecting the automake version. Is this an acceptable solution?
   
If this works, then we can decide on whether we want to patch it for
   older
( 1.13) or newer (= 1.13) automake version. Is there a preference
   there?
   
Kapil
   
On Thu, Jun 25, 2015 at 2:30 PM, Jake Farrell jfarr...@apache.org
   wrote:
   
 we encountered a lot of issues in thrift between all the backwards
 incompatible changes automake had in 1.12 to 1.14 and trying to
  support
all
 the default versions across different distros. due to this we are
switching
 to cmake as well

 -Jake


 On Thu, Jun 25, 2015 at 1:46 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com
 wrote:

  What about CentOS 5 and 6?
  https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
 
  Also, how does this interact with the effort to use CMake?
  https://issues.apache.org/jira/browse/MESOS-898
 
  On Thu, Jun 25, 2015 at 10:40 AM, Kapil Arya 
 ka...@mesosphere.io
 wrote:
 
   Hi All,
  
   First off, I am not sure if we record the minimum required
  version
   of
   automake/autoconf somewhere in the documentation.
  
   Having said that, I want to propose to move to automake 1.13 in
   order
 to
  be
   able to use the AM_EXTRA_RECURSIVE_TARGETS macro which allows
  us
   to
  add a
   test target to just build the test and not run it. The issue
 is
 tracked
   at https://issues.apache.org/jira/browse/MESOS-2273 and the
  corresponding
   RRs have received some ship-its.
  
   Best,
   Kapil
  
   ==
   Compatibility notes:
   Automake 1.13 came out in 2013 and here is the compatibility
  status
for
   leading distros:
   * Debian: Since 8.0 [1].
   * Ubuntu: Since 13.10 [2].
   * Fedora: Since Fedora 20 [3].
   * Centos: Since 7.0 [4].
  
   1. https://packages.debian.org/jessie/automake
   2. https://launchpad.net/ubuntu/trusty/+package/automake
   3. https://apps.fedoraproject.org/packages/automake
   4. http://mirror.centos.org/centos/7/os/x86_64/Packages/
  
 

   
  
 

Re: Enabling 'network' namespace for custom network isolators

[Kapil Arya]

Hi All,

I have now filed a Jira ticket (MESOS-2884)[1] and created a couple of
RRs[2] along the lines of the suggestions provided by Ian and Jie.

There is one difference though. Instead of creating a LinuxIsolator class,
I added the `int namespaces()` directly to Isolator class. By default, it
returns '0' and thus allows for a simplified approach. By creating
LinuxIsolator, we would then have a complicated lookup logic in
MesosContainerizer to first figure out the subclass type and then call
namespaces() on it.

From here on, I think we can continue the discussion on the Jira ticket if
no one has any objections.

Best,
Kapil

[1]. https://issues.apache.org/jira/browse/MESOS-2884
[2a]. https://reviews.apache.org/r/35585/
[2b]. https://reviews.apache.org/r/35586/

On Mon, May 11, 2015 at 7:42 PM, Niklas Nielsen nik...@mesosphere.io
wrote:

 (inlined)

 On 11 May 2015 at 14:30, Kapil Arya ka...@mesosphere.io wrote:

  On Mon, May 11, 2015 at 4:58 PM, Jie Yu yujie@gmail.com wrote:
 
   
Yes. The simplest (cleanest?) way that I see would be to refactor the
launcher to take the desired flags when executing the executor, i.e.,
(Linux)Launcher::fork() takes the namespace flags. The launcher would
  be
directed which namespaces to create by the caller, not inferring them
itself from any flags: the MesosContainerizer in turn would determine
   this
based on the isolators it was using for the container (querying
 them).
   This
also facilitates the MesosContainerizer having different isolators,
 and
thus namespaces, for different containers.
  
  
   +1
  
   For instance, the isolator could have an interface 'int namespaces()'
  which
   specifies the namespaces needed. The launcher can just query that and
  pass
   them to the linux launcher.
  
   Since currently, the launcher and isolator interfaces are designed for
  both
   mac and linux and namespace does not make sense on Mac, we probably
 need
  a
   LinuxIsolator interface (inherit from Isolator) and a LinuxLauncher
   interface (inherit from Launcher).
  
 
  This is a good idea. I think this will keep things pretty clean and
  readable within Mesos and for the Isolators.
 
 
   - Jie
  
   On Mon, May 11, 2015 at 1:29 PM, Ian Downes
 idow...@twitter.com.invalid
  
   wrote:
  

 TLDR: We want to use a custom network isolator, but there is no way
  to
 enable the 'network' namespace from within an isolator module.


 We are working on creating a custom network isolator as a Mesos
  module.
 However, the way Mesos Slave is setup, there is no way to enable
'network'
 namespace for the executor without enabling the 'port-mapping'
   isolator.
 This is due to the fact that the LinuxLauncher looks at the
   '--isolation'
 flag to figure out the list of namespaces to be enabled. The same
   problem
 would exist if one were to write a custom pid or filesystem
 isolation
 module.

   
Curious, are these going to be open source and added to the codebase
 or
will they be proprietary modules? What specifically is lacking in the
existing network and pid isolators? Could we extend those?
 

 We will be bringing in a dependency, experimental work with Calico, and
 wanted to be flexible in how we call out to our tools.


   
So, there are a couple of question:

 1. With the current Mesos source code, is there a way to specify
 the
 'network/port_mapping' isolator in a way that it doesn't do the
  actual
work
 of mapping the ports (e.g., without specifying any port-mapping
   specific
 flags)? If this works, we can just specify this isolator on the
 slave
 command line and it would force the LinuxLauncher to create a new
   network
 namespace.
   
   
No, as written they're coupled.
   
2. Is it reasonable to have a separate mechanism to specify what
   namespaces
 should be created/enabled for an executor if we don't want to use
 the
 in-built isolators such as pid and port-mapping?
   
   
Yes. The simplest (cleanest?) way that I see would be to refactor the
launcher to take the desired flags when executing the executor, i.e.,
(Linux)Launcher::fork() takes the namespace flags. The launcher would
  be
directed which namespaces to create by the caller, not inferring them
itself from any flags: the MesosContainerizer in turn would determine
   this
based on the isolators it was using for the container (querying
 them).
   This
also facilitates the MesosContainerizer having different isolators,
 and
thus namespaces, for different containers.
   
WRT (2), one potential mechanism is to introduce a new flag,
   '--namespace'.
 The downside of creating such a low-level flag is that it provides
   little
 to no value to the end users. The end users shouldn't be concerned
   about
 which namespaces to enable and so on
 
  
   
That seems unduly onerous to the user

Re: Enabling 'network' namespace for custom network isolators

[Kapil Arya]

On Mon, May 11, 2015 at 4:29 PM, Ian Downes idow...@twitter.com.invalid
wrote:

 
  TLDR: We want to use a custom network isolator, but there is no way to
  enable the 'network' namespace from within an isolator module.
 
 
  We are working on creating a custom network isolator as a Mesos module.
  However, the way Mesos Slave is setup, there is no way to enable
 'network'
  namespace for the executor without enabling the 'port-mapping' isolator.
  This is due to the fact that the LinuxLauncher looks at the '--isolation'
  flag to figure out the list of namespaces to be enabled. The same problem
  would exist if one were to write a custom pid or filesystem isolation
  module.
 

 Curious, are these going to be open source and added to the codebase or
 will they be proprietary modules?


As of now, the custom isolator module is very much WIP as we are exploring
the design space and so not sure if would be closed or open source.


 What specifically is lacking in the
 existing network and pid isolators? Could we extend those?


There is no pid isolator in works right now. I just used it as an example
to describe the problem. The custom network isolator is pretty much useless
without a network namespace :-).


 So, there are a couple of question:
 
  1. With the current Mesos source code, is there a way to specify the
  'network/port_mapping' isolator in a way that it doesn't do the actual
 work
  of mapping the ports (e.g., without specifying any port-mapping specific
  flags)? If this works, we can just specify this isolator on the slave
  command line and it would force the LinuxLauncher to create a new network
  namespace.


 No, as written they're coupled.

 2. Is it reasonable to have a separate mechanism to specify what namespaces
  should be created/enabled for an executor if we don't want to use the
  in-built isolators such as pid and port-mapping?


 Yes. The simplest (cleanest?) way that I see would be to refactor the
 launcher to take the desired flags when executing the executor, i.e.,
 (Linux)Launcher::fork() takes the namespace flags. The launcher would be
 directed which namespaces to create by the caller, not inferring them
 itself from any flags: the MesosContainerizer in turn would determine this
 based on the isolators it was using for the container (querying them). This
 also facilitates the MesosContainerizer having different isolators, and
 thus namespaces, for different containers.


This is a good idea.

WRT (2), one potential mechanism is to introduce a new flag, '--namespace'.
  The downside of creating such a low-level flag is that it provides little
  to no value to the end users. The end users shouldn't be concerned about
  which namespaces to enable and so on


 That seems unduly onerous to the user and almost as rigid.


  Another alternative is to create a decorator hook for the LinuxLauncher,
  which can force the LinuxLauncher to enable certain namespaces without
  having to look at the '--isolation' flag. The downside here is that the
  decorator will be literally setting up a few bits and nothing more.
 

 I don't think there's a need for a decorator hook, just refactoring to pass
 in through fork() is sufficient?


Agreed.



 Are there any other alternatives for a better and cleaner design (both long
  term and short term)?
 

 Happy to chat further about this.

 ian

Re: Enabling 'network' namespace for custom network isolators

[Kapil Arya]

On Mon, May 11, 2015 at 4:58 PM, Jie Yu yujie@gmail.com wrote:

 
  Yes. The simplest (cleanest?) way that I see would be to refactor the
  launcher to take the desired flags when executing the executor, i.e.,
  (Linux)Launcher::fork() takes the namespace flags. The launcher would be
  directed which namespaces to create by the caller, not inferring them
  itself from any flags: the MesosContainerizer in turn would determine
 this
  based on the isolators it was using for the container (querying them).
 This
  also facilitates the MesosContainerizer having different isolators, and
  thus namespaces, for different containers.


 +1

 For instance, the isolator could have an interface 'int namespaces()' which
 specifies the namespaces needed. The launcher can just query that and pass
 them to the linux launcher.

 Since currently, the launcher and isolator interfaces are designed for both
 mac and linux and namespace does not make sense on Mac, we probably need a
 LinuxIsolator interface (inherit from Isolator) and a LinuxLauncher
 interface (inherit from Launcher).


This is a good idea. I think this will keep things pretty clean and
readable within Mesos and for the Isolators.


 - Jie

 On Mon, May 11, 2015 at 1:29 PM, Ian Downes idow...@twitter.com.invalid
 wrote:

  
   TLDR: We want to use a custom network isolator, but there is no way to
   enable the 'network' namespace from within an isolator module.
  
  
   We are working on creating a custom network isolator as a Mesos module.
   However, the way Mesos Slave is setup, there is no way to enable
  'network'
   namespace for the executor without enabling the 'port-mapping'
 isolator.
   This is due to the fact that the LinuxLauncher looks at the
 '--isolation'
   flag to figure out the list of namespaces to be enabled. The same
 problem
   would exist if one were to write a custom pid or filesystem isolation
   module.
  
 
  Curious, are these going to be open source and added to the codebase or
  will they be proprietary modules? What specifically is lacking in the
  existing network and pid isolators? Could we extend those?
 
  So, there are a couple of question:
  
   1. With the current Mesos source code, is there a way to specify the
   'network/port_mapping' isolator in a way that it doesn't do the actual
  work
   of mapping the ports (e.g., without specifying any port-mapping
 specific
   flags)? If this works, we can just specify this isolator on the slave
   command line and it would force the LinuxLauncher to create a new
 network
   namespace.
 
 
  No, as written they're coupled.
 
  2. Is it reasonable to have a separate mechanism to specify what
 namespaces
   should be created/enabled for an executor if we don't want to use the
   in-built isolators such as pid and port-mapping?
 
 
  Yes. The simplest (cleanest?) way that I see would be to refactor the
  launcher to take the desired flags when executing the executor, i.e.,
  (Linux)Launcher::fork() takes the namespace flags. The launcher would be
  directed which namespaces to create by the caller, not inferring them
  itself from any flags: the MesosContainerizer in turn would determine
 this
  based on the isolators it was using for the container (querying them).
 This
  also facilitates the MesosContainerizer having different isolators, and
  thus namespaces, for different containers.
 
  WRT (2), one potential mechanism is to introduce a new flag,
 '--namespace'.
   The downside of creating such a low-level flag is that it provides
 little
   to no value to the end users. The end users shouldn't be concerned
 about
   which namespaces to enable and so on
 
 
  That seems unduly onerous to the user and almost as rigid.
 
 
   Another alternative is to create a decorator hook for the
 LinuxLauncher,
   which can force the LinuxLauncher to enable certain namespaces without
   having to look at the '--isolation' flag. The downside here is that the
   decorator will be literally setting up a few bits and nothing more.
  
 
  I don't think there's a need for a decorator hook, just refactoring to
 pass
  in through fork() is sufficient?
 
  Are there any other alternatives for a better and cleaner design (both
 long
   term and short term)?
  
 
  Happy to chat further about this.
 
  ian
 

Enabling 'network' namespace for custom network isolators

[Kapil Arya]

Hi All,

TLDR: We want to use a custom network isolator, but there is no way to
enable the 'network' namespace from within an isolator module.


We are working on creating a custom network isolator as a Mesos module.
However, the way Mesos Slave is setup, there is no way to enable 'network'
namespace for the executor without enabling the 'port-mapping' isolator.
This is due to the fact that the LinuxLauncher looks at the '--isolation'
flag to figure out the list of namespaces to be enabled. The same problem
would exist if one were to write a custom pid or filesystem isolation
module.

So, there are a couple of question:

1. With the current Mesos source code, is there a way to specify the
'network/port_mapping' isolator in a way that it doesn't do the actual work
of mapping the ports (e.g., without specifying any port-mapping specific
flags)? If this works, we can just specify this isolator on the slave
command line and it would force the LinuxLauncher to create a new network
namespace.

2. Is it reasonable to have a separate mechanism to specify what namespaces
should be created/enabled for an executor if we don't want to use the
in-built isolators such as pid and port-mapping?

WRT (2), one potential mechanism is to introduce a new flag, '--namespace'.
The downside of creating such a low-level flag is that it provides little
to no value to the end users. The end users shouldn't be concerned about
which namespaces to enable and so on.

Another alternative is to create a decorator hook for the LinuxLauncher,
which can force the LinuxLauncher to enable certain namespaces without
having to look at the '--isolation' flag. The downside here is that the
decorator will be literally setting up a few bits and nothing more.

Are there any other alternatives for a better and cleaner design (both long
term and short term)?

Best,
Kapil

Re: Review Request 29947: Fixed a race condition in hook tests for remove-executor hook.

[Kapil Arya]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29947/
---

(Updated April 21, 2015, 2:44 p.m.)


Review request for mesos and Niklas Nielsen.


Changes
---

Addressed Nik's comments.


Bugs: MESOS-2226
https://issues.apache.org/jira/browse/MESOS-2226


Repository: mesos


Description (updated)
---

There is currently no good way to synchronize between the test body and the 
hook code, so we wire a promise (owned by the test code). The technical debt is 
covered by the following JIRA issue:

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


Diffs (updated)
-

  src/examples/test_hook_module.cpp 2f2da1c5ef85af06c7f366d38ce5b64f39d0076f 
  src/tests/hook_tests.cpp bb9de25bd2c4601d333a3ca1aec13820c7df7378 

Diff: https://reviews.apache.org/r/29947/diff/


Testing
---

make check


Thanks,

Kapil Arya