Re: [VOTE] Move Apache Mesos to Attic

[Till Toenshoff]

> On 5. Apr 2021, at 19:58, Vinod Kone  wrote:
> 
> Hi folks,
> 
> Based on the recent conversations 
> 
>  on our mailing list, it seems to me that the majority consensus among the 
> existing PMC is to move the project to the attic  
> and let the interested community members collaborate on a fork in Github.
> 
> I would like to call a vote to dissolve the PMC and move the project to the 
> attic. 
> 
> Please reply to this thread with your vote. Only binding votes from 
> PMC/committers count towards the final tally but everyone in the community is 
> encouraged to vote. See process here .
> 
> Thanks,



+1 for move to attic.

Re: Next Steps

[Till Toenshoff]

+1 to what Renan (and Benjamin) suggested.

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

[Till Toenshoff]

+1

Build using Apple clang version 12.0.0 (clang-1200.0.32.27) and ran on macOS 
11.0.1 (20B29).

> On 17. Nov 2020, at 15:53, Andrei Sekretenko  wrote:
> 
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 1.11.0.
> 
> 1.11.0 includes the following:
> 
>  * CSI external volumes support: now, Mesos Containerizer supports using
>pre-provisioned external CSI storage volumes by means of the new
> `volume/csi`
>isolator. Also, the latter significantly extends the range of
> compatible 3rd party
>   CSI plugins compared to the previous SLRP-based solution
> (MESOS-10141).
> 
>  * Constraints-based offer filtering: the Scheduler API adds an
> interface allowing
>frameworks to put constraints  on agent attributes in resource
> offers to help "picky"
>frameworks significantly reduce scheduling latency when close to
> being out of quota
>(MESOS-10161).
> 
>  * CMake build becomes usable for deploying in production (MESOS-898).
> 
> The CHANGELOG for the release is available at:
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.11.0-rc1
> 
> 
> The candidate for Mesos 1.11.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.11.0-rc1/mesos-1.11.0.tar.gz
> 
> The tag to be voted on is 1.11.0-rc1:
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.11.0-rc1
> 
> The SHA512 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.11.0-rc1/mesos-1.11.0.tar.gz.sha512
> 
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.11.0-rc1/mesos-1.11.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-1260
> 
> Please vote on releasing this package as Apache Mesos 1.11.0!
> 
> The vote is open until 2020 Nov 20th 15:00 UTC at least, and passes if
> a majority of at least 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Mesos 1.11.0
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> Andrei Sekretenko

Re: Mesos on ssl

[Till Toenshoff]

The “unknown bug in libevent” was in fact a bug in libprocess (our layer on top 
of libevent). See https://issues.apache.org/jira/browse/MESOS-9265 
 for more.
Even though we do bundle libevent 2.0.22, we don’t need to - Mesos >= 1.8.0 is 
compatible with all recent versions of libevent since we fixed that above issue 
in libprocess.

> On 12. Apr 2019, at 00:51, Vinod Kone  wrote:
> 
> Hi Jorge. We are hoping to cut 1.8.0 RC within a week.
> 
> -- Vinod
> 
> 
> On Fri, Apr 5, 2019 at 12:06 PM Jorge Machado  wrote:
> 
>> Thanks Hsiao, I think it is this, as a build from master works fine for
>> me. When are we releasing 1.8.0 ?
>> 
>> 
>> 
>>> On 5 Apr 2019, at 16:52, Chun-Hung Hsiao  wrote:
>>> 
>>> I'm not sure if this is related:
>>> https://issues.apache.org/jira/browse/MESOS-7076
>>> 
>>> In summary, Ubuntu 18.04 ships libevent 2.1.x (for OpenSSL 1.1.x
>> support).
>>> But libevent 2.1.x has an unknown bug that caused some Mesos tests to
>> fail.
>>> As a workaround, the current Mesos master branch (will be 1.8 soon)
>> bundled
>>> libevent 2.0.x with a magic patch from Debian 8 for OpenSSL 1.1.x). So
>>> Mesos 1.8 will be the first official release supporting SSL on Ubuntu
>> 18.04.
>>> 
>>> That said, I'm not sure what you encountered is exactly the same bug that
>>> caused the Mesos tests to fail though. Just a guess ;)
>>> 
>>> On Fri, Apr 5, 2019, 12:58 AM Jorge Machado 
>> wrote:
>>> 
 Hi Guys,
 
 I'm having issues with mesos versions from tar.gz compared with a build
 from git master when using ssl.
 With a build from git ssl agent is fine and for example the endpoint
 https://mesos-agent:5051/ returns a 404 which is fine.
 With a build from tar.gz (1.7.1 or 1.7.2) the same endpoint does not
>> work
 and it just hangs. No logs nothing...
 I'm testing this on ubuntu 18.04.
 
 Any tipps ?
 thanks
 Jorge
 
 
 Jorge Machado
 www.jmachado.me
 
 
 
 
 
 
>> 
>> 

Re: Shut down modules@mesos mailing list ?

[Till Toenshoff]

Agreed.

> On 20. Jan 2019, at 23:34, sebb  wrote:
> 
> The modules@ mailing list looks as though it is not needed and should
> be shut down.
> 
> It has had very few postings - none in 2018.
> 
> Agreed?
> 
> Sebb.

Libevent bundling ahead.

[Till Toenshoff]

Hey All,

We are considering bundling/vendoring libevent 2.0.22 with upcoming releases of 
Mesos.

Let me explain the motivation and then go into some details.

Due to https://issues.apache.org/jira/browse/MESOS-7076, SSL builds Mesos 
stopped functioning on distributions that offer libevent 2.1.8 by default. 
Specifically the failure was observed on Ubuntu 17/18 as well as on macOS. It 
has also just come to my attention that Fedora 18 shares the same fate. So the 
problem is less likely OS specific but more likely libevent + SSL + libprocess 
specific.
Instead of getting stuck in the rabbit hole of debugging right away, I decided 
that bundling a known good version of libevent was the most reliable way to 
prevent sad faces when building Mesos with SS but instead we can be sure SSL 
builds of Mesos function properly across all supported platforms, out of the 
box.

Details on the bundling;
We will include libevent 2.0.22 and we also include a patch that makes that 
version build against both openssl 1.0.x as well as 1.1.x. For unbundled builds 
(--with-libevent) I have some additional checks foreseen that try to prevent a 
build of a known bad variant of libevent + SSL + Mesos.

The bundling and those checks are a workaround, not a solution. I still am 
pursueing debugging the underlying cause. However, way too much time has passed 
already without a proper solution, hence this suggestion of a quick fix, 
bundling workaround.

Let me know your thoughts!

cheers,
Till

Re: RFC: update C++ style to require the "override" keyword

[Till Toenshoff]

+1 — that feature as saved us from nasty issues already when working on 
internal modules.

> On Jul 9, 2018, at 8:43 AM, Zhitao Li  wrote:
> 
> +1
> 
> On Sun, Jul 8, 2018 at 10:55 PM Benjamin Bannier <
> benjamin.bann...@mesosphere.io> wrote:
> 
>> Hi James,
>> 
>>> I’d like to propose that we update our style to require that the
>>> “override” keyword always be used when overriding virtual functions
>>> (including destructors). The proposed text is below. I’ll also prepare
>>> a clang-tidy patch to update stout, libprocess and mesos globally.
>> 
>> +1!
>> 
>> Thanks for bringing this up and offering to do the clean-up. Using
>> `override`
>> consistently would really give us some certainty as interface methods
>> evolve.
>> 
>> * * *
>> 
>> Note that since our style guide _is_ the Google style guide plus some
>> additions, we shouldn't need to update anything in our style guide; the
>> Google
>> style guide seems to have started requiring this from February this year
>> and
>> our code base just got out of sync.
>> 
>> I believe we should activate the matching warning in our `cpplint` setup,
>> 
>>--- a/support/mesos-style.py
>>+++ b/support/mesos-style.py
>>@@ -256,6 +256,7 @@ class CppLinter(LinterBase):
>> 'build/endif_comment',
>> 'build/nullptr',
>> 'readability/todo',
>>+'readability/inheritance',
>> 'readability/namespace',
>> 'runtime/vlog',
>> 'whitespace/blank_line',
>> 
>> 
>> While e.g., `clang` already emits a diagnostic for hidden `virtual`
>> functions
>> we might still want to update our `clang-tidy` setup. There is a dedicated
>> linter for `override` which me might not need due to the default
>> diagnostic,
>> 
>>--- a/support/clang-tidy
>>+++ b/support/clang-tidy
>>@@ -25,6 +25,7 @@ google-*,\
>> mesos-*,\
>> \
>> misc-use-after-move,\
>>+modernize-use-override,\
>> \
>> readability-redundant-string-cstr\
>> "
>> 
>> but it probably makes a lot of sense to check what other compile-time Mesos
>> features can be enabled by default in our `clang-tidy` setup (either in
>> Jenkins
>> via `CMAKE_ARGS`, or even better globally by default in
>> `support/mesos-tidy/entrypoint.sh:31ff`).
>> 
>> I would guess that using `cpplint` to verifying automated fixes made with
>> `clang-tidy` could inform what flags should have been added (there are some
>> missing features in the cmake build though, e.g., some isolators which
>> would
>> have benefited from `override` recently).
>> 
>> 
>> Cheers,
>> 
>> Benjamin
>> 
>> 
> 
> -- 
> Cheers,
> 
> Zhitao Li

Shall we move SASL based CRAM-MD5 authentication out of libmesos?

[Till Toenshoff]

Dear fellow Apache Mesos developers,

as you know, Apache Mesos supports authentication on various levels - among 
those is the RPC-style authentication allowing frameworks and agents to 
authenticate against the master. Even though  this authentication interface has 
been modularized a long time ago, we still kept the default, SASL based 
challenge-response authentication mechanism, message digest 5 (aka CRAM-MD5)  
authentication within libmesos. 

Modularizing of our RPC authentication has enabled you to add new 
authentication mechanisms. User have chosen authentication fitting their 
company security landscape - e.g. ticket based things like Kerberos or 
Mesosphere’s use of JWT. It has also come to my attention that there are users 
out there using directory backed (e.g.LDAP) variants - or even combinations of 
those like LDAP backed Kerberos.

CRAM-MD5, while still being regarded as secure, is not very convenient or 
flexible and therefor in my experience it is not chosen in production 
environments.  This in turn means that all those builds of libmesos drag SASL 
in as a dependency while in fact not making any use of it - and that is what I 
would like to have fixed (since ages). It would benefit in reducing loading 
times of libmesos dependent runnable and it would also reduce provisioning 
complexity.

To fix that, we would have SASL CRAM-MD5 be available as a module exclusively, 
provisioned only when really needed. That in turn means that users of this 
mechanism would need to additionally provide the “modules” or “modules_dir” 
flag to master, agent and/or framework - that would a breaking change for those 
that rely on the fact that CRAM-MD5 works out of the box.

I could imagine ways where the user would not even have to provide that 
“modules*” flag and we internal generate that data for him as a convenience 
function - it is another option.

Given that CRAM-MD5 is the only RPC authentication mechanism Mesos is bundling 
right now and given that our tests do rely on authentication to be available 
and tested, we will not be able to remove the dependency against SASL entirely 
for building and testing.

This first step would only ease the deployment.

But, there is a drawback - Windows builds currently do not support modules. So 
either we get modules support for Windows up and running OR we would need to 
let Windows be an exception to this plan for now. 

What do you think? Is it worth following this path - or do you have other 
suggestions?

Feel free to comment here or on 
https://issues.apache.org/jira/browse/MESOS-9042 
.

Thanks for your feedback,
Till

Re: [Proposal] Use jemalloc as default memory allocator for Mesos

[Till Toenshoff]

Ow, I forgot my actual vote :)

+1 for using jemalloc
+1 for making it non bundled
+1 for using it by default if the configuration phase locates it

> On Aug 25, 2017, at 3:28 PM, Benno Evers  wrote:
> 
> Hi Jeff,
> 
> from looking around on the internet, it seems like Firefox builds with
> jemalloc on all platforms, and I've also seen reports of people
> successfully using tcmalloc heap profiling on windows. I'm afraid I don't
> currently have a Windows machine with development environment set up, so I
> can't provide direct user experience.
> 
> In the worst case, we would have to disable jemalloc-support on windows,
> but I hope it won't be necessary.
> 
> Since you probably have more experience with memory management on windows,
> is there a reason to suspect that it should or shouldn't work?
> 
> Best regards,
> Benno
> 
> On Wed, Aug 23, 2017 at 6:16 PM, Jeff Coffler <
> jeff.coff...@microsoft.com.invalid> wrote:
> 
>> Hi Benno,
>> 
>> What's the availability of both jemalloc and tcmalloc on the Windows
>> platform? Do the products work there properly?
>> 
>> There are solutions that I know work on Windows (from past work I've
>> done). I'm unsure about either jemalloc and tcmalloc, however.
>> 
>> Thanks,
>> 
>> /Jeff
>> 
>> -Original Message-
>> From: Benno Evers [mailto:bev...@mesosphere.com]
>> Sent: Tuesday, August 22, 2017 3:16 AM
>> To: dev@mesos.apache.org
>> Subject: Re: [Proposal] Use jemalloc as default memory allocator for Mesos
>> 
>> Hi Alexander,
>> 
>> in general, jemalloc and tcmalloc are very similar, and seem to be taking
>> ideas from each other (in fact the jeprof executable started as a copy of
>> pprof and there are still references the pprof documentation in some
>> comments)
>> 
>> From what I've seen, the main difference is that the profiling seems
>> better-suited to multi-threaded programs, in particular the profile file
>> format includes per-thread memory statistics and the profiling features can
>> be turned on and off individually per thread. From an API perspective, all
>> settings can be accessed by the mallctl() function, while it seems that
>> tcmalloc requires some options to be set by environment variable (
>> https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgperftools.github.io%2Fgperftools%
>> 2Fheapprofile.html=02%7C01%7CJeff.Coffler%40microsoft.com%
>> 7Ccb0bfb1eb3e242c0dd4108d4e946d709%7C72f988bf86f141af91ab2d7cd011
>> db47%7C1%7C0%7C636389937852256730=IQeb2%
>> 2BpcrWRQ8yvdTgOEHfyplgC36dy73nnXswdPamo%3D=0). Finally, I also
>> found the documentation to be more thorough.
>> 
>> But again, the two are very similar, so I think the main decision here
>> isn't whether to choose jemalloc or tcmalloc but whether to switch to a
>> custom memory allocator that has support for profiling heap memory usage.
>> 
>> 
>> On Mon, Aug 21, 2017 at 4:26 PM, Alexander Rojas 
>> wrote:
>> 
>>> Hi Benno,
>>> 
>>> This does sound like a great addition to Mesos. Can you however
>>> explain how jemalloc is better than tcmalloc? I think that for such
>>> important change, we probably need some more information.
>>> 
>>> Your comment in MESOS-7876 mentions that we already have tcmalloc
>>> since it is part of gperftools, so I would like to have a whole
>>> picture of the advantages and disadvantages of both options.
>>> 
>>> Alexander Rojas
>>> alexan...@mesosphere.io
>>> 
>>> 
>>> 
>>> 
 On 18. Aug 2017, at 12:49, Benno Evers  wrote:
 
 Hi all,
 
 I would like to propose bundling jemalloc as a new dependency under
 `3rdparty/`, and to link Mesos against this new memory allocator by
 default.
 
 
 # Motivation
 
 The Mesos master and agent binaries are, ideally, very long-running
 processes. This makes them susceptible to memory issues, because
 even small leaks have a chance to build up over time to the point
 where they become problematic.
 
 We have seen several such issues on our internal Mesos
 installations, for example
 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fiss
 ues.apache.org%2Fjira%2Fbrowse%2FMESOS-7748=02%7C01%7CJeff.Coff
 ler%40microsoft.com%7Ccb0bfb1eb3e242c0dd4108d4e946d709%7C72f988bf86f
 141af91ab2d7cd011db47%7C1%7C0%7C636389937852266742=L016YGyEkK5
 0WtvhgSNS%2FT5ntkkd9qINorRI2Utp5lk%3D=0
 or https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FMESOS-
>> 7800=02%7C01%7CJeff.Coffler%40microsoft.com%
>> 7Ccb0bfb1eb3e242c0dd4108d4e946d709%7C72f988bf86f141af91ab2d7cd011
>> db47%7C1%7C0%7C636389937852266742=IrzDO6o1VL9a8eGJIW3jKbWXk6U4fH
>> Fn3Xbn4po1r3c%3D=0.
 
 I imagine any organization running Mesos for an extended period of
 time has had its share of similar issues, so I expect this proposal
 to be useful for the whole community.
 
 
 # Why jemalloc?
 
 Given that 

Re: [Proposal] Use jemalloc as default memory allocator for Mesos

[Till Toenshoff]

It appears that jemalloc does support Windows (64bit) 
See: https://github.com/jemalloc/jemalloc/blob/dev/msvc/ReadMe.txt 


tcmalloc on the other hand appears to only offer a minimal variant on Windows.
See: https://github.com/gperftools/gperftools 
 - grep for "COMPILING ON NON-LINUX 
SYSTEMS”
See: https://github.com/gperftools/gperftools/blob/master/INSTALL 
 - grep for 
“Windows  (MSVC, Cygwin, and MinGW)"

So both options rely on Cygwin or MinGW for building - a requirement that the 
Mesos build itself does not have and proves your point of stuff not really 
“just working” at least when it comes to the build step of those packages.

Seems that without trying it, we won’t find out if jemalloc works as hoped on 
Windows for us - the Firefox project results however are encouraging. On the 
other hand, if it doesn’t work, we could simply decide to disable it on Windows 
just like some other Mesos features will remain disabled on that platform 
unless someone decides to port them -  e.g. SASL based authn.

> On Aug 25, 2017, at 3:28 PM, Benno Evers  wrote:
> 
> Hi Jeff,
> 
> from looking around on the internet, it seems like Firefox builds with
> jemalloc on all platforms, and I've also seen reports of people
> successfully using tcmalloc heap profiling on windows. I'm afraid I don't
> currently have a Windows machine with development environment set up, so I
> can't provide direct user experience.
> 
> In the worst case, we would have to disable jemalloc-support on windows,
> but I hope it won't be necessary.
> 
> Since you probably have more experience with memory management on windows,
> is there a reason to suspect that it should or shouldn't work?
> 
> Best regards,
> Benno
> 
> On Wed, Aug 23, 2017 at 6:16 PM, Jeff Coffler <
> jeff.coff...@microsoft.com.invalid> wrote:
> 
>> Hi Benno,
>> 
>> What's the availability of both jemalloc and tcmalloc on the Windows
>> platform? Do the products work there properly?
>> 
>> There are solutions that I know work on Windows (from past work I've
>> done). I'm unsure about either jemalloc and tcmalloc, however.
>> 
>> Thanks,
>> 
>> /Jeff
>> 
>> -Original Message-
>> From: Benno Evers [mailto:bev...@mesosphere.com]
>> Sent: Tuesday, August 22, 2017 3:16 AM
>> To: dev@mesos.apache.org
>> Subject: Re: [Proposal] Use jemalloc as default memory allocator for Mesos
>> 
>> Hi Alexander,
>> 
>> in general, jemalloc and tcmalloc are very similar, and seem to be taking
>> ideas from each other (in fact the jeprof executable started as a copy of
>> pprof and there are still references the pprof documentation in some
>> comments)
>> 
>> From what I've seen, the main difference is that the profiling seems
>> better-suited to multi-threaded programs, in particular the profile file
>> format includes per-thread memory statistics and the profiling features can
>> be turned on and off individually per thread. From an API perspective, all
>> settings can be accessed by the mallctl() function, while it seems that
>> tcmalloc requires some options to be set by environment variable (
>> https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fgperftools.github.io%2Fgperftools%
>> 2Fheapprofile.html=02%7C01%7CJeff.Coffler%40microsoft.com%
>> 7Ccb0bfb1eb3e242c0dd4108d4e946d709%7C72f988bf86f141af91ab2d7cd011
>> db47%7C1%7C0%7C636389937852256730=IQeb2%
>> 2BpcrWRQ8yvdTgOEHfyplgC36dy73nnXswdPamo%3D=0). Finally, I also
>> found the documentation to be more thorough.
>> 
>> But again, the two are very similar, so I think the main decision here
>> isn't whether to choose jemalloc or tcmalloc but whether to switch to a
>> custom memory allocator that has support for profiling heap memory usage.
>> 
>> 
>> On Mon, Aug 21, 2017 at 4:26 PM, Alexander Rojas 
>> wrote:
>> 
>>> Hi Benno,
>>> 
>>> This does sound like a great addition to Mesos. Can you however
>>> explain how jemalloc is better than tcmalloc? I think that for such
>>> important change, we probably need some more information.
>>> 
>>> Your comment in MESOS-7876 mentions that we already have tcmalloc
>>> since it is part of gperftools, so I would like to have a whole
>>> picture of the advantages and disadvantages of both options.
>>> 
>>> Alexander Rojas
>>> alexan...@mesosphere.io
>>> 
>>> 
>>> 
>>> 
 On 18. Aug 2017, at 12:49, Benno Evers  wrote:
 
 Hi all,
 
 I would like to propose bundling jemalloc as a new dependency under
 `3rdparty/`, and to link Mesos against this new memory allocator by
 default.
 
 
 # Motivation
 
 The Mesos master and agent binaries are, ideally, very long-running
 processes. This makes them susceptible to memory issues, because
 even small leaks have a chance to build up over time to the point

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

[Till Toenshoff]

+1

Tested on internal CI as well as on macOS 10.12 and macOS 10.13 DP 8 using 
Apple’s clang (Xcode 8.3.3 and Xcode 9.0.0 beta 6).

> On Aug 27, 2017, at 8:33 PM, Vinod Kone  wrote:
> 
> +1 (binding)
> 
> Tested on ASF CI. The only red build was the known perf core dump issue.
> 
> Revision: ce77d91bd3a59227d5684ce0783b460c54ea311f
> refs/tags/1.1.3-rc2
> Configuration Matrix  gcc clang
> centos:7  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
> 
> cmake 
>  
> 
>   
> 
> --verbose autotools   
>  
> 
>  
> 
> cmake 
>  
> 
>  
> 
> ubuntu:14.04  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
>  
> 
> cmake 
>  
> 
>   
>  
> 
> --verbose autotools   
>  
> 
>  
>  
> 
> cmake 
>  
> 
>  
>  
> 
> 
> On Fri, Aug 25, 2017 at 7:48 AM, Alex Rukletsov  > wrote:
> Folks,
> 
> Please vote on releasing the following candidate as Apache Mesos 1.1.3. Note 
> that this will be the last 1.1.x release.
> 
> 1.1.3 includes the following:
> 
> ** Bug
>  * [MESOS-5187] - The filesystem/linux isolator does not set the permissions 
> of the host_path.
>   * [MESOS-6743] - Docker executor hangs forever if `docker stop` fails.
>   * [MESOS-6950] - Launching two tasks with the same Docker image 
> simultaneously may cause a staging dir never cleaned up.
>   * [MESOS-7540] - Add an agent flag for executor re-registration timeout.
>   * [MESOS-7569] - Allow "old" executors with half-open connections to be 
> preserved during agent upgrade / restart.
>   * [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.

Re: Dropping support for Apple Clang

[Till Toenshoff]

Which version of Apple’s clang did you try for C++14? The latest version 
available is Apple LLVM version 9.0.0 (clang-900.0.22.8).

> On Jul 29, 2017, at 2:38 AM, Michael Park  wrote:
> 
> I'd like to drop support for Apple Clang.
> 
> With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> compiler. In most cases it only takes a few commands to get a newer
> compiler. This is also true of OS X, where clang-4.0 can be easily
> installed with `brew install llvm`.
> 
> The current codebase does not compile with Apple Clang under C++14 mode. We
> could choose to investigate whether this is a Mesos bug or an Apple Clang
> bug, but after doing a brief investigation myself, I feel like it's not
> worth the effort. There are already cases where we need to install a new
> compiler on OS X due to Apple Clang releases based on clang-3.8 (MESOS-5745
> ).
> 
> Not that Apple Clang was "officially" supported anyway, but we have had
> minor workarounds (e.g., THREAD_LOCAL) to support it.
> 
> Please let me know what you think!
> 
> Thanks,
> 
> MPark

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

[Till Toenshoff]

+1

Ran on internal CI. All failures I saw were well documented flaky tests.


> On May 13, 2017, at 12:26 AM, Vinod Kone  wrote:
> 
> +1 (binding)
> 
> Ran on ASF CI. The one configuration that is in "red" is due to a known flaky 
> issue with perf core dump during test suite teardown.
> 
> Revision: 37d98c55e1f43d6734729b5cdbed242ebc3263ed
> refs/tags/1.1.2-rc2
> Configuration Matrix  gcc clang
> centos:7  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
> 
> cmake 
>  
> 
>   
> 
> --verbose autotools   
>  
> 
>  
> 
> cmake 
>  
> 
>  
> 
> ubuntu:14.04  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
>  
> 
> cmake 
>  
> 
>   
>  
> 
> --verbose autotools   
>  
> 
>  
>  
> 
> cmake 
>  
> 
>  
>  
> 
> 
> On Fri, May 12, 2017 at 8:07 AM, Alex Rukletsov  > wrote:
> Folks,
> 
> Please vote on releasing the following candidate as Apache Mesos 1.1.2.
> 
> 1.1.2 includes the following:
> 
> ** Bug
>   * [MESOS-2537] - AC_ARG_ENABLED checks are broken.
>   * [MESOS-5028] - Copy provisioner cannot replace directory with symlink.
>   * [MESOS-5172] - Registry puller cannot fetch blobs correctly from http
> Redirect 3xx urls.
>   * [MESOS-6327] - Large docker images causes container launch failures:
> Too many levels of symbolic links.
>   * [MESOS-7057] - Consider using the relink functionality of libprocess in
> the executor driver.
>   * [MESOS-7119] - Mesos master crash while accepting inverse offer.
>   * [MESOS-7152] - The agent may be flapping after the machine reboots due
> to provisioner recover.
>   * [MESOS-7197] - Requesting tiny amount of CPU crashes master.
>   * [MESOS-7210] - HTTP health check 

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

[Till Toenshoff]

+1

Ran on internal CI. All failures I saw were well documented flaky tests.

> On May 13, 2017, at 12:26 AM, Vinod Kone  wrote:
> 
> +1 (binding)
> 
> Ran on ASF CI. The one configuration that is in "red" is due to a known
> flaky issue with perf core dump during test suite teardown.
> 
> *Revision*: 37d98c55e1f43d6734729b5cdbed242ebc3263ed
> 
>   - refs/tags/1.1.2-rc2
> 
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Failed]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 
> --verbose autotools
> [image: Success]
> 
> [image: Success]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 
> 
> On Fri, May 12, 2017 at 8:07 AM, Alex Rukletsov  wrote:
> 
>> Folks,
>> 
>> Please vote on releasing the following candidate as Apache Mesos 1.1.2.
>> 
>> 1.1.2 includes the following:
>> 
>> 
>> ** Bug
>>  * [MESOS-2537] - AC_ARG_ENABLED checks are broken.
>>  * [MESOS-5028] - Copy provisioner cannot replace directory with symlink.
>>  * [MESOS-5172] - Registry puller cannot fetch blobs correctly from http
>> Redirect 3xx urls.
>>  * [MESOS-6327] - Large docker images causes container launch failures:
>> Too many levels of symbolic links.
>>  * [MESOS-7057] - Consider using the relink functionality of libprocess in
>> the executor driver.
>>  * [MESOS-7119] - Mesos master crash while accepting inverse offer.
>>  * [MESOS-7152] - The agent may be flapping after the machine reboots due
>> to 

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

[Till Toenshoff]

+1

Ran it through DC/OS builds and integration tests;
https://github.com/dcos/dcos/pull/1530  
=> all green

> On May 17, 2017, at 10:01 PM, Vinod Kone  wrote:
> 
> Ran it on ASF CI and saw some issues. 
> 
> Segfault in "MasterTest.MultipleExecutors"  in two builds [1] 
> 
>  [2 
> ],
>  which is concerning. Is this a known issue?
> 
> "ContentType/AgentAPIStreamingTest.AttachInputToNestedContainerSession" test 
> failed 
> .
> 
> 
> 
> On Sun, May 14, 2017 at 12:55 AM, tommy xiao  > wrote:
> +1
> 
> 2017-05-12 7:33 GMT+08:00 Adam Bordelon  >:
> 
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.2.1.
> >
> > 1.2.1 is a bug fix release. The CHANGELOG for the release is available at:
> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_ 
> > 
> > plain;f=CHANGELOG;hb=1.2.1-rc1
> >
> > The candidate for Mesos 1.2.1 release is available at:
> > https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/mesos-1.2.1.tar.gz 
> > 
> >
> > The tag to be voted on is 1.2.1-rc1:
> > https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.2.1-rc1 
> > 
> >
> > The MD5 checksum of the tarball can be found at:
> > https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/ 
> > 
> > mesos-1.2.1.tar.gz.md5
> >
> > The signature of the tarball can be found at:
> > https://dist.apache.org/repos/dist/dev/mesos/1.2.1-rc1/ 
> > 
> > mesos-1.2.1.tar.gz.asc
> >
> > The PGP key used to sign the release is here:
> > https://dist.apache.org/repos/dist/release/mesos/KEYS 
> > 
> >
> > The JAR is up in Maven in a staging repository here:
> > https://repository.apache.org/content/repositories/orgapachemesos-1192 
> > 
> >
> > Please vote on releasing this package as Apache Mesos 1.2.1!
> >
> > The vote is open until Tue May 16 17:00 PDT 2017 and passes if a majority
> > of at least 3 +1 PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Mesos 1.2.1
> > [ ] -1 Do not release this package because ...
> >
> > Thanks,
> > -Adam-
> >
> 
> 
> 
> --
> Deshi Xiao
> Twitter: xds2000
> E-mail: xiaods(AT)gmail.com 
> 

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

[Till Toenshoff]

+1

Tested on:
- macOS 10.12.4 Beta (16E175b): ok
- centos 6: mostly ok, MESOS-4736
- centos 7: internal CI issues on capabilities tests, otherwise fine
- debian 8: mostly ok, MESOS-7213
- fedora 23: ok
- ubuntu 12.04: mostly ok, MESOS-7218
- ubuntu 14.04: mostly ok, MESOS-7218
- ubuntu 16.04: mostly ok, MESOS-7218


> On Mar 4, 2017, at 1:09 AM, Vinod Kone  wrote:
> 
> +1 (binding)
> 
> Since the perf issue I reported earlier doesn't seem to be a blocker.
> 
> On Fri, Mar 3, 2017 at 12:14 AM, Alex Rukletsov  > wrote:
> Was this perf issue introduced by one of the fixes included in 1.1.1-rc2?
> If not, I would suggest we vote for 1.1.1-rc2 and back port the perf fix
> into 1.1.2. IIUC, time based patch releases should *not be worse*, hence if
> the perf issue was already in 1.1.0 it is *fine* to fix it in 1.1.2. I
> would like to avoid postponing already belated 1.1.1 for even longer.
> 
> On Wed, Mar 1, 2017 at 8:02 PM, Vinod Kone  > wrote:
> 
> > Tested on ASF CI.
> >
> > Saw 2 configurations fail with
> > https://issues.apache.org/jira/browse/MESOS-7160 
> > 
> >
> > I think @jpeach and @bbannier were looking into this. Not sure about the
> > severity of the issue, so withholding my vote.
> >
> >
> > *Revision*: b9d8202a7444d0d1e49476bfc9817eb4583beaff
> >
> >- refs/tags/1.1.1-rc2
> >
> > Configuration Matrix gcc clang
> > centos:7 --verbose --enable-libevent --enable-ssl autotools
> > [image: Success]
> >  > 
> > Release/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose%20--
> > enable-libevent%20--enable-ssl,ENVIRONMENT=GLOG_v=1%
> > 20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%7C%
> > 7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > cmake
> > [image: Success]
> >  > 
> > Release/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> > verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> > GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_exp=(docker%
> > 7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > --verbose autotools
> > [image: Success]
> >  > 
> > Release/30/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
> > ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
> > exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > cmake
> > [image: Success]
> >  > 
> > Release/30/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--
> > verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%
> > 3A7,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > [image: Not run]
> > ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> > [image: Success]
> >  > 
> > Release/30/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]
> >  > 
> > Release/30/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/30/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/30/BUILDTOOL=cmake,COMPILER=clang,CONFIGURATION=-
> > -verbose%20--enable-libevent%20--enable-ssl,ENVIRONMENT=
> > GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(
> > docker%7C%7CHadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2)/>
> > --verbose autotools
> > [image: Success]
> >  > 
> > 

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

[Till Toenshoff]

-1 for https://issues.apache.org/jira/browse/MESOS-7133 
 


> On Feb 8, 2017, at 10:39 PM, Vinod Kone  wrote:
> 
> +1 (binding)
> 
> Tested on ASF CI.
> 
>   Revision: 5d4c9962930c3f5c08e802caff40b670424cb091
> refs/tags/1.1.1-rc1
> Configuration Matrix  gcc clang
> centos:7  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
> 
> cmake 
>  
> 
>   
> 
> --verbose autotools   
>  
> 
>  
> 
> cmake 
>  
> 
>  
> 
> ubuntu:14.04  --verbose --enable-libevent --enable-sslautotools   
>  
> 
>   
>  
> 
> cmake 
>  
> 
>   
>  
> 
> --verbose autotools   
>  
> 
>  
>  
> 
> cmake 
>  
> 
>  
>  
> 
> 
> On Wed, Feb 8, 2017 at 9:09 AM, Kapil Arya  > wrote:
> +1 binding.
> 
> Internal CI to build deb/rpm packages.
> 
> The deb/rpm binary packages are available at:
> http://open.mesosphere.com/downloads/mesos-rc/#apache-mesos-1.1.1-rc1 
> 
> 
> 
> On Tue, Feb 7, 2017 at 5:39 PM, Alex R  > wrote:
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 1.1.1.
> 
> 1.1.1 includes the following:
> 
> ** Bug
>   * [MESOS-6002] - The whiteout file cannot be removed correctly using aufs 
> backend.
>   * [MESOS-6010] - Docker registry puller shows decode error "No response 
> decoded".
>   * [MESOS-6142] - Frameworks may RESERVE for an arbitrary role.
>   * [MESOS-6360] - The handling of whiteout files in provisioner is not 
> correct.
>   * [MESOS-6411] - Add documentation for CNI port-mapper plugin.
>   * [MESOS-6526] - `mesos-containerizer launch 

Re: Hook Deprecation: slavePreLaunchDockerEnvironmentDecorator

[Till Toenshoff]

Yes, thanks for these additions Adam - much appreciated.

…and while we are at it, we will also remove the `slavePreLaunchDockerHook` 
which is equally superseded by that new hook.


> On Nov 29, 2016, at 7:46 PM, Adam Bordelon <a...@mesosphere.io> wrote:
> 
> + dev@, in case some module developers haven't joined the modules@ list yet.
> So this will require code changes (and a recompile) so any module
> implementing the previous hook must now use the new hook, potentially
> updating to set both environments instead of just the one. Such a hook
> compiled against Mesos 1.1 will not work anymore with Mesos 1.2.
> 
> On Tue, Nov 29, 2016 at 10:15 AM, Till Toenshoff <toensh...@me.com> wrote:
> 
>> Hey Folks,
>> 
>> we are removing the slave sided, docker specific hook callback `
>> slavePreLaunchDockerEnvironmentDecorator` and replace it with `
>> slavePreLaunchDockerTaskExecutorDecorator`.
>> 
>> The latter now allows setting two individual environments, one effective
>> for the task and one for the executor. Note that as usual, a custom
>> executor itself may still decide to make (parts of) the executor
>> environment available to its task/s.
>> 
>> We decided to use a protobuf message return signature for that hook,
>> allowing us to add things like e.g. volumes without having to come up with
>> another hook callback — see discussion around https://issues.apache.org/
>> jira/browse/MESOS-6396?focusedCommentId=15654316=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-15654316.
>> 
>> The changes involved should have no extra side-effects - your
>> functionality is unaffected if you don't use custom hooks.
>> 
>> Please remember that hooks are still considered experimental and may still
>> evolve fast.
>> 
>> 
>> Let me know what you think!
>> 
>> Till

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

[Till Toenshoff]

+1

Tested `make distcheck`:

With SSL.
MacOS 10.12.1 (16B2555) => OK

With SSL and without.
Centos 7 => OK
Debian 8 => OK
Fedora 23 => OK
Ubuntu 14 => OK
Ubuntu 12 => OK
Ubuntu 15 => OK
Ubuntu 16 => OK


> On Nov 7, 2016, at 8:24 PM, Vinod Kone  wrote:
> 
> Hi all,
> 
> 
> 
> Please vote on releasing the following candidate as Apache Mesos 1.0.2.
> 
> 
> 
> This is a bug fix release.
> 
> 
> 
> 
> The CHANGELOG for the release is available at:
> 
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.0.2-rc3
>  
> 
> 
> 
> 
> 
> The candidate for Mesos 1.0.2 release is available at:
> 
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc3/mesos-1.0.2.tar.gz 
> 
> 
> The tag to be voted on is 1.0.2-rc3:
> 
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=1.0.2-rc3 
> 
> 
> The MD5 checksum of the tarball can be found at:
> 
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc3/mesos-1.0.2.tar.gz.md5 
> 
> 
> The signature of the tarball can be found at:
> 
> https://dist.apache.org/repos/dist/dev/mesos/1.0.2-rc3/mesos-1.0.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-1168 
> 
> 
> Please vote on releasing this package as Apache Mesos 1.0.2!
> 
> 
> 
> The vote is open until Thu Nov 10 11:22:30 PST 2016 and passes if a majority 
> of at least 3 +1 PMC votes are cast.
> 
> 
> 
> [ ] +1 Release this package as Apache Mesos 1.0.2
> 
> [ ] -1 Do not release this package because ...
> 
> 
> 
> Thanks,
> 

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

[Till Toenshoff]

Hi all,

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

+1 (Binding)
--
Vinod Kone <vinodk...@apache.org>
Alex Ruskletkow <a...@mesosphere.com>
Till Toenshoff <toensh...@me.com>

+1 (Non-binding)
--
Benno Evers <ben...@yandex-team.ru <mailto:ben...@yandex-team.ru>>
Li Zhitao <zhitaoli...@gmail.com <mailto:zhitaoli...@gmail.com>>


There were no 0 or -1 votes.

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

The mesos-1.1.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,
Alex & Till

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

[Till Toenshoff]

+1

Tested by make distcheck (root) on...
MacOS 10.12.1 (16B2555), plain & SSL => ok
CentOS 7, plain & SSL => ok
Debian 8, plain & SSL => ok
Fedora 23, plain & SSL => ok
Ubuntu 12, plain & SSL => ok
Ubuntu 14, plain & SSL => ok


> On Nov 10, 2016, at 11:47 AM, Alex Rukletsov <a...@mesosphere.com> wrote:
> 
> +1 (binding)
> 
> make check locally + manually tested health checks with the locally
> modified mesos-execute.
> 
> On Wed, Nov 9, 2016 at 6:13 PM, Zhitao Li <zhitaoli...@gmail.com> wrote:
> 
>> +1 (non-binding)
>> 
>> Tested with ROOT and docker on debian jessie.
>> 
>> On Mon, Nov 7, 2016 at 2:19 PM, Vinod Kone <vinodk...@apache.org> wrote:
>> 
>>> +1 (binding)
>>> 
>>> Tested on ASF CI.
>>> 
>>> *Revision*: a44b077ea0df54b77f05550979e1e97f39b15873
>>> 
>>>   - refs/tags/1.1.0-rc3
>>> 
>>> 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/23/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)/>
>>> [image: Not run]
>>> cmake
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/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)/>
>>> [image: Not run]
>>> --verbose autotools
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/BUILDTOOL=autotools,COMPILER=gcc,CONFIGURATION=--verbose,
>>> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=centos%3A7,label_
>>> exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)/>
>>> [image: Not run]
>>> cmake
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/BUILDTOOL=cmake,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 autotools
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/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)/>
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/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)/>
>>> cmake
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/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)/>
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/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)/>
>>> --verbose autotools
>>> [image: Success]
>>> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-
>>> Release/23/BUILDTOOL=autotools,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/23/BUILDTOOL=autotools,COMPILER=clang,CONFIGURATION=--verbose,
>>> ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,
>>> label_exp=(docker%7C%7CHadoop)&&(!ubu

[VOTE] Release Apache Mesos 1.1.0 (rc3)

[Till Toenshoff]

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 the updated `HealthCheck` protobuf to implement
HTTP(S) health checks. Both default executors (command and docker) leverage
`curl` binary for sending HTTP(S) requests and connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, for BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-3421] - **Experimental** Support sharing of resources across
containers. Currently persistent volumes are the only resources allowed to
be shared.

  * [MESOS-3567] - **Experimental** support for TCP health checks. Executors
may now use the updated `HealthCheck` protobuf to implement TCP health
checks. Both default executors (command and docker) connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, for BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-4324] - Allow tasks to access persistent volumes in either a
read-only or read-write manner. Using a volume in read-only mode can
simplify sharing that volume between multiple tasks on the same agent.

  * [MESOS-5275] - **Experimental** support for linux capabilities. Frameworks
or operators now have fine-grained control over the capabilities that a
container may have. This allows a container to run as root, but not have all
the privileges associated with the root user (e.g., CAP_SYS_ADMIN).

  * [MESOS-5344] - **Experimental** support for partition-aware Mesos
frameworks. In previous Mesos releases, when an agent is partitioned from
the master and then reregisters with the cluster, all tasks running on the
agent are terminated and the agent is shutdown. In Mesos 1.1, partitioned
agents will no longer be shutdown when they reregister with the master. By
default, tasks running on such agents will still be killed (for backward
compatibility); however, frameworks can opt-in to the new PARTITION_AWARE
capability. If they do this, their tasks will not be killed when a partition
is healed. This allows frameworks to define their own policies for how to
handle partitioned tasks. Enabling the PARTITION_AWARE capability also
introduces a new set of task states: TASK_UNREACHABLE, TASK_DROPPED,
TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These new states are
intended to eventually replace the TASK_LOST state.

  * [MESOS-5788] - **Experimental** support for Java scheduler adapter. This
adapter allows framework developers to toggle between the old/new API
(driver/scheduler library) implementations, thereby allowing them to easily
transition their frameworks to the new v1 Scheduler API.

  * [MESOS-6014] - **Experimental** A new port-mapper CNI plugin, the
`mesos-cni-port-mapper` has been introduced. For Mesos containers, with the
CNI port-mapper plugin, users can now expose container ports through host
ports using DNAT. This is especially useful when Mesos containers are
attached to isolated CNI networks such as private bridge networks, and the
services running in the container needs to be exposed outside these
isolated networks.

  * [MESOS-6077] - **Experimental** A new default executor is introduced which
frameworks can use to launch task groups as nested containers. All the
nested containers share resources likes cpu, memory, network and volumes.

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.1.0-rc3


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc3/mesos-1.1.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-1166

Please vote on releasing this package as Apache Mesos 

[VOTE] Release Apache Mesos 1.1.0 (rc2)

[Till Toenshoff]

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 the updated `HealthCheck` protobuf to implement
HTTP(S) health checks. Both default executors (command and docker) leverage
`curl` binary for sending HTTP(S) requests and connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-3421] - **Experimental** Support sharing of resources across
containers. Currently persistent volumes are the only resources allowed to
be shared.

  * [MESOS-3567] - **Experimental** support for TCP health checks. Executors
may now use the updated `HealthCheck` protobuf to implement TCP health
checks. Both default executors (command and docker) connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-4324] - Allow access to persistent volumes as read-only or read-write
by tasks. Mesos doesn't allow persistent volumes to be created as read-only
but in 1.1 it starts allow tasks to use the volumes as read-only. This is
mainly motivated by shared persistent volumes but applies to regular
persistent volumes as well.

  * [MESOS-5275] - **Experimental** support for linux capabilities. Frameworks
or operators now have fine-grained control over the capabilities that a
container may have. This allows a container to run as root, but not have all
the privileges associated with the root user (e.g., CAP_SYS_ADMIN).

  * [MESOS-5344] -- **Experimental** support for partition-aware Mesos
frameworks. In previous Mesos releases, when an agent is partitioned from
the master and then reregisters with the cluster, all tasks running on the
agent are terminated and the agent is shutdown. In Mesos 1.1, partitioned
agents will no longer be shutdown when they reregister with the master. By
default, tasks running on such agents will still be killed (for backward
compatibility); however, frameworks can opt-in to the new PARTITION_AWARE
capability. If they do this, their tasks will not be killed when a partition
is healed. This allows frameworks to define their own policies for how to
handle partitioned tasks. Enabling the PARTITION_AWARE capability also
introduces a new set of task states: TASK_UNREACHABLE, TASK_DROPPED,
TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These new states are
intended to eventually replace the TASK_LOST state.

  * [MESOS-6077] - **Experimental** A new default executor is introduced which
frameworks can use to launch task groups as nested containers. All the
nested containers share resources likes cpu, memory, network and volumes.

  * [MESOS-6014] - **Experimental** A new port-mapper CNI plugin, the
`mesos-cni-port-mapper` has been introduced. For Mesos containers, with the
CNI port-mapper plugin, users can now expose container ports through host
ports using DNAT. This is especially useful when Mesos containers are
attached to isolated CNI networks such as private bridge networks, and the
services running in the container needs to be exposed outside these
isolated networks.


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


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/1.1.0-rc2/mesos-1.1.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-1162

Please vote on releasing this package as Apache Mesos 1.1.0!

The vote is open until Thu Nov  3 14:46:55 CET 2016 and passes if a majority of 
at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 

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

[Till Toenshoff]

Quick update on RC2 - we are still waiting for one blocker - cut will follow 
the solution of MESOS-6497.

[VOTE] Release Apache Mesos 1.1.0 (rc1)

[Till Toenshoff]

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 the updated `HealthCheck` protobuf to implement
HTTP(S) health checks. Both default executors (command and docker) leverage
`curl` binary for sending HTTP(S) requests and connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-3421] - **Experimental** Support sharing of resources across
containers. Currently persistent volumes are the only resources allowed to
be shared.

  * [MESOS-3567] - **Experimental** support for TCP health checks. Executors
may now use the updated `HealthCheck` protobuf to implement TCP health
checks. Both default executors (command and docker) connect to `127.0.0.1`,
hence a task must listen on all interfaces. On Linux, For BRIDGE and USER
modes, docker executor enters the task's network namespace.

  * [MESOS-4324] - Allow access to persistent volumes as read-only or read-write
by tasks. Mesos doesn't allow persistent volumes to be created as read-only
but in 1.1 it starts allow tasks to use the volumes as read-only. This is
mainly motivated by shared persistent volumes but applies to regular
persistent volumes as well.

  * [MESOS-5275] - **Experimental** support for linux capabilities. Frameworks
or operators now have fine-grained control over the capabilities that a
container may have. This allows a container to run as root, but not have all
the privileges associated with the root user (e.g., CAP_SYS_ADMIN).

  * [MESOS-5344] -- **Experimental** support for partition-aware Mesos
frameworks. In previous Mesos releases, when an agent is partitioned from
the master and then reregisters with the cluster, all tasks running on the
agent are terminated and the agent is shutdown. In Mesos 1.1, partitioned
agents will no longer be shutdown when they reregister with the master. By
default, tasks running on such agents will still be killed (for backward
compatibility); however, frameworks can opt-in to the new PARTITION_AWARE
capability. If they do this, their tasks will not be killed when a partition
is healed. This allows frameworks to define their own policies for how to
handle partitioned tasks. Enabling the PARTITION_AWARE capability also
introduces a new set of task states: TASK_UNREACHABLE, TASK_DROPPED,
TASK_GONE, TASK_GONE_BY_OPERATOR, and TASK_UNKNOWN. These new states are
intended to eventually replace the TASK_LOST state.

  * [MESOS-6077] - **Experimental** A new default executor is introduced which
frameworks can use to launch task groups as nested containers. All the
nested containers share resources likes cpu, memory, network and volumes.

  * [MESOS-6014] - **Experimental** A new port-mapper CNI plugin, the
`mesos-cni-port-mapper` has been introduced. For Mesos containers, with the
CNI port-mapper plugin, users can now expose container ports through host
ports using DNAT. This is especially useful when Mesos containers are
attached to isolated CNI networks such as private bridge networks, and the
services running in the container needs to be exposed outside these
isolated networks.


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


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

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

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

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

Please vote on releasing this package as Apache Mesos 1.1.0!

The vote is open until Fri Oct 21 21:57:02 CEST 2016 and passes if a majority 
of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 

Re: 1.1.0 release

[Till Toenshoff]

Latest news; We dp still have blocking issues. The release cut is being delayed
once again towards the end-of-day, today. That gives us the weekend to prepare 
a release candidate.

Some blocking issues that did not show any progress or communication were now
re-targeted in silent consensus.

Alex & Till

> On  Oct 12, 2016, at 2:11 PM, Alex Rukletsov <a...@mesosphere.io> wrote:
> 
> Folks,
> 
> we have 23 unresolved tickets targeted for Mesos 1.1.0 release, including 7
> blockers and 3 epics (MESOS-5344, MESOS-3421, MESOS-2449), which turns 23
> into 55. Obviously, we can’t make a cut today.
> 
> Shepherds please either commit your blockers by Thu EOD PST or declare them
> as non-blockers. For unfinished epics, please transition all unresolved
> tickets to a new epic (see previous email) or retarget the epic. Make sure
> CHANGELOG is in good shape.
> 
> We strive to cut the release on Fri Oct 14 around 13:00 CEST. At that time
> we will bulk-transit all unresolved tickets to 1.2.
> 
> Rigorously,
> Alex & Till
> 
> On Tue, Oct 11, 2016 at 5:30 PM, Alex Rukletsov <a...@mesosphere.io> wrote:
> 
>> Folks,
>> 
>> in preparation for Mesos 1.1.0 release we would like to ask people who
>> have worked on features in 1.1.0 to either:
>> * update the CHANGELOG and declare the feature implemented or
>> experimental, make sure documentation is updated as well;
>> * postpone to 1.2 and update the related epic;
>> * promote an experimental feature to stable if necessary.
>> 
>> If you think you need to land something in 1.1.0, please mark the
>> respective JIRA as a blocker and set the target version to 1.1.0. Bear in
>> mind the release cut will be cut *tomorrow*, Oct 12 2016.
>> 
>> For experimental features, consider creating a separate epic and moving
>> all unresolved tickets there, while marking the original epic as resolved
>> for 1.1.0. For example, see MESOS-2449 (pods) and MESOS-6355
>> (pods-improvements).
>> 
>> Below is the list of candidates for the CHAGELOG update with their
>> respective owners:
>> MESOS-6014 CNI port-mapping Avinash, Jie
>> MESOS-2449 Pods, subtopics: nested containers, nested isolators, default
>> executor Vinod
>> MESOS-5676 New Mesos CLI Kevin
>> MESOS-4697 Unified Cgroups isolator Haosdent, Jie
>> MESOS-6007 v1 API Anand, Vinod
>> MESOS-3302 - // -
>> MESOS-4855 - // -
>> MESOS-4791 - // -
>> MESOS-4766 Allocator performance BenM
>> MESOS-4936 Container security Jie
>> MESOS-4936 Capabilities and container security Benjamin Bannier, Jie
>> MESOS-3421 Shared resources Yan Xu
>> MESOS-5344 Partition awareness  Neil
>> 
>> Below is the list of features marked as experimental in 1.0. Are they
>> ready to be promoted and called out in the CHANGELOG?
>> MESOS-4312 Power PC Vinod
>> MESOS-4828 XFS disk isolator Yan Xu
>> MESOS-4641 Network CNI isolator Qian, Jie
>> MESOS-3094 Mesos tasks on Windows Joseph
>> MESOS-4355 Docker volume isolator Guangya, Qian, Jie
>> 
>> This one has never been even called experimental. Joseph, is it time to do
>> so?
>> MESOS-898 CMake (never declared even experimental) Joseph
>> 
>> Thanks in advance for cooperation,
>> Till and AlexR
>> 
>> On Fri, Oct 7, 2016 at 7:47 PM, Vinod Kone <vinodk...@apache.org> wrote:
>> 
>>> I think you need to clean up the JIRA a bit.
>>> 
>>> 1) Make sure unresolved tickets do not have fix version (1.1.0) set.
>>> 2) Move "Fix version 1.1.0" to "Target version 1.1.0".
>>> 
>>> 2) might obviate the need for 1).
>>> 
>>> 
>>> 
>>> On Fri, Oct 7, 2016 at 7:24 AM, Till Toenshoff <toensh...@me.com> wrote:
>>> 
>>>> Hi everyone!
>>>> 
>>>> its us who will be the Release Managers for 1.1.0 - Alex and Till!
>>>> 
>>>> We are planning to cut the next release (1.1.0) within three workdays -
>>>> that would be Wednesday next week. So, if you have any patches that need to
>>>> get into 1.1.0 make sure that either is already in the master branch or the
>>>> corresponding ticket has a target version set to 1.1.0.
>>>> 
>>>> The release dashboard:
>>>> https://issues.apache.org/jira/secure/Dashboard.jspa?selectP
>>>> ageId=12329720
>>>> 
>>>> Alex & Till
>>>> 
>>> 
>>> 
>> 

Re: A Plan for Mesos Community Syncs

[Till Toenshoff]

+1 - Thanks MPark!

> On Oct 13, 2016, at 10:34 PM, Michael Park  wrote:
> 
> I would like to try to get the community syncs back on track. They have not
> been organized well recently, and I would like to take ownership of being
> the driver/host of the meetings. I think my half-involved driving of the
> meetings have been detrimental in terms of logistics, consistency,
> experience and ultimately the attendance, and I apologize for this. I also
> think that it's been difficult to rotate between the timezones without
> clear designation of hosts and an inability of many to attend across
> timezones.
> 
> Going forward, we'll have a community sync every other Thursday at 3pm PST,
> starting Oct 20. This is to facilitate getting back to a good cadence with
> consistent hosting (that's on me), with an agenda and regular attendance.
> We can certainly seek for others who can help run the meetings in other
> timezones, but I believe this can come later.
> 
> If you disagree, or opposed to any of what I've said above, please let me
> know.
> 
> Thank you,
> 
> MPark

1.1.0 release

[Till Toenshoff]

Hi everyone!

its us who will be the Release Managers for 1.1.0 - Alex and Till! 

We are planning to cut the next release (1.1.0) within three workdays - that 
would be Wednesday next week. So, if you have any patches that need to get into 
1.1.0 make sure that either is already in the master branch or the 
corresponding ticket has a target version set to 1.1.0.

The release dashboard:
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12329720 


Alex & Till

Re: I want to a contributor

[Till Toenshoff]

Hi Kreats,

I have added you to the list of contributors in our JIRA - welcome to Mesos!

best,
Till

> On Feb 22, 2016, at 10:05 AM, 周想想  wrote:
> 
> Hi:
>   I’m a c++ programmer, and I want to be a contributor of mesos.
> 
>   Mesos is a great project, we have used it for a few months.
>  I want to be a member of it.
> 
> 
> - - - - - - - - - - - - - - - - -
> Kreats
> 2.22 2016
> 

Re: are mesos package version names predictable?

[Till Toenshoff]

Hey Erik,

those added values (e.g. “-0.2.190") come from Mesosphere's CI system which 
adds build-numbers (the last digit) and some more “noise" for those 
distribution packages.

I will raise this issue internally and get back to you - hoping that we can get 
rid of these not so useful extensions in a not too distant future.

hth,
Till

 
> On Feb 3, 2016, at 2:23 AM, Erik Weathers  
> wrote:
> 
> I've noticed that in the published mesos packages [1] & docker images [2]
> that the version name isn't simply:
> 
>   -  mesos_0.27.0.ubuntu1404_amd64
> 
> Instead it has the form of:
> 
>   - mesos_0.27.0*-0.2.190*.ubuntu1404_amd64
> 
> Here are a few more examples of this numeric suffix:
> 
>   - 0.27.0 -> 0.27.0-0.2.190
>   - 0.26.0 -> 0.26.0-0.2.145
>   - 0.25.0 -> 0.25.0-0.2.70
>   - 0.24.1 -> 0.24.1-0.2.35
>   - 0.24.0 -> 0.24.0-1.0.27
> 
> It is not clear to me what these suffixes represent, and it makes it hard
> to write code that can download or install the mesos package for a
> particular version given just the simple version name (e.g., 0.27.0).  I
> tried searching for what might be generating this version suffix, or for
> documentation of the release process for mesos, but I have failed.
> 
> So my question is really 2-fold:
> (1) Where does this extra suffix come from?  Does it represent something
> specific?  What is its purpose?   Why isn't the version simply the version?
> (I'm sure there *is* a reason, but I haven't found it on my own.)
> (2) What is the "right" way to handle this seeming unpredictability?
> 
> Thanks!
> 
> - Erik
> 
> References:
> [1] http://open.mesosphere.com/downloads/mesos/
> [2] https://hub.docker.com/r/mesosphere/mesos/tags/

Re: are mesos package version names predictable?

[Till Toenshoff]

Given that the final number (build number) is constantly being raised, I fear 
there is really not much you can do. The “0.2” and “1.0” were originally 
planned for snapshots (0.2) vs. releases (1.0) but as you can see, we changed 
that over time.

The only robust option I see right now is a mapping table as you drafted in 
your initial mail already. You would have to touch that mapping with each new 
release :(

… but hope is in sight, for future releases at least… will keep you updated.

> On Feb 4, 2016, at 11:07 PM, Erik Weathers <eweath...@groupon.com.INVALID> 
> wrote:
> 
> hey Till, thanks for the response!   Would be great to have those
> CI-build-numbers squelched in the future if possible.  Or some sort of
> alias set up to allow redirecting to the fully expanded build.
> 
> Any suggestions for the short term of how to perform this redirection?  For
> reference, the purpose of this is to allow the storm-on-mesos project's
> Dockerfile to have a configurable mesos version.
> 
>   - https://github.com/mesos/storm/pull/91
> 
> - Erik
> 
> On Thu, Feb 4, 2016 at 1:51 PM, Till Toenshoff <toensh...@me.com> wrote:
> 
>> Hey Erik,
>> 
>> those added values (e.g. “-0.2.190") come from Mesosphere's CI system
>> which adds build-numbers (the last digit) and some more “noise" for those
>> distribution packages.
>> 
>> I will raise this issue internally and get back to you - hoping that we
>> can get rid of these not so useful extensions in a not too distant future.
>> 
>> hth,
>> Till
>> 
>> 
>>> On Feb 3, 2016, at 2:23 AM, Erik Weathers <eweath...@groupon.com.INVALID>
>> wrote:
>>> 
>>> I've noticed that in the published mesos packages [1] & docker images [2]
>>> that the version name isn't simply:
>>> 
>>>  -  mesos_0.27.0.ubuntu1404_amd64
>>> 
>>> Instead it has the form of:
>>> 
>>>  - mesos_0.27.0*-0.2.190*.ubuntu1404_amd64
>>> 
>>> Here are a few more examples of this numeric suffix:
>>> 
>>>  - 0.27.0 -> 0.27.0-0.2.190
>>>  - 0.26.0 -> 0.26.0-0.2.145
>>>  - 0.25.0 -> 0.25.0-0.2.70
>>>  - 0.24.1 -> 0.24.1-0.2.35
>>>  - 0.24.0 -> 0.24.0-1.0.27
>>> 
>>> It is not clear to me what these suffixes represent, and it makes it hard
>>> to write code that can download or install the mesos package for a
>>> particular version given just the simple version name (e.g., 0.27.0).  I
>>> tried searching for what might be generating this version suffix, or for
>>> documentation of the release process for mesos, but I have failed.
>>> 
>>> So my question is really 2-fold:
>>> (1) Where does this extra suffix come from?  Does it represent something
>>> specific?  What is its purpose?   Why isn't the version simply the
>> version?
>>> (I'm sure there *is* a reason, but I haven't found it on my own.)
>>> (2) What is the "right" way to handle this seeming unpredictability?
>>> 
>>> Thanks!
>>> 
>>> - Erik
>>> 
>>> References:
>>> [1] http://open.mesosphere.com/downloads/mesos/
>>> [2] https://hub.docker.com/r/mesosphere/mesos/tags/
>> 
>> 

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

[Till Toenshoff]

+1

Debian 8.2: 
configure && make check -> ok,
sudo mesas-tests.sh -> two failures due to enabled swapping, one known flaky.
configure —enable-ssl —enable-libevent && make check -> ok
sudo mesas-tests.sh -> two failures due to enabled swapping, one known flaky, 
one more flaky test (now known as MESOS-4570)

CentOS 7.1.1503: 
configure && make check -> ok

OSX 10.11.4 beta: 
configure && make check -> ok


> On Jan 30, 2016, at 8:32 AM, Marco Massenzio  wrote:
> 
> +1 (non-binding)
> 
> ran all tests (including ROOT) on Ubuntu 14.04 [0]
> 
> Thanks, guys!
> 
> 
> [0] $ lsb_release -a
> LSB Version:
> core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> 
> 
> -- 
> Marco Massenzio
> http://codetrips.com 
> 
> On Fri, Jan 29, 2016 at 5:04 PM, Joris Van Remoortere  > wrote:
> +1 (binding)
> 
> Tested on  Ubuntu 15.04:
> Built with clang-3.6 and gcc-4.8.
> Launched 1K agents.
> Launched 100K tasks (slowly) on 100 agents.
> Validated virtual memory set did not grow.
> Validate UI was responsive.
> Validate task recovery with 0.26 Master -> 0.27 Master with 0.27 Agent 
> constant.
> Validate task recovery with 0.26 Master -> 0.26 Master with 0.26 Agent 
> constant.
> Validate task recovery with 0.26 Agent -> 0.27 Agent with 0.26 Master 
> constant.
> Validate task recovery with 0.26 Agent -> 0.27 Agent with 0.27 Master 
> constant.
> Validated constrained framework when quota set.
> Validated framework received remaining offers if quota set on a separate role.
> Broken not considered blockers (Feel free to decide they are a blocker):
> Web UI task count is off (MESOS-4562)
> I was not able to verify the docker containerizer tests in my environment.
> 
> On Fri, Jan 29, 2016 at 1:45 PM, Vinod Kone  > wrote:
> +1 (binding)
> 
> Tested (non-root tests with ./support/docker_build.sh script) on ASF CI
>  >with
> the following configurations:
> 
> NOTE: clang is intentionally disabled on centos and "clang + ubuntu +
> --verbose" build failed because of a docker image building issue (not mesos
> issue).
> 
> 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: Success]
> 

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

[Till Toenshoff]

Hi friends,

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

+1 (Binding)
--
Joris Van Remoortere
Brenden Matthews
Benjamin Mahler
Bernd Mathiske 
Till Toenshoff

+1 (Non-binding)
--
Alexander Rojas

There were no 0 or -1 votes.

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

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

Bernd & Till

[VOTE] Release Apache Mesos 0.26.0 (rc5)

[Till Toenshoff]

Hi friends,

we did unfortunately, once again run into an issue that needed immediate 
attention (see vote on rc4), hence we have to ask for another round of testing 
and voting of this newest release-candidate.

The issue leading to this new release candidate was 
https://issues.apache.org/jira/browse/MESOS-4106 
. Apart from that, we also 
pulled in a fix for https://issues.apache.org/jira/browse/MESOS-4015 
 as we believe it has minimal 
additional risk while being very useful for some of us.

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

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.0-rc5


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.26.0-rc5/mesos-0.26.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-1095

Please vote on releasing this package as Apache Mesos 0.26.0!

The vote is open until Tue Dec 15 22:35:22 CET 2015 and passes if a majority of 
at least 3 +1 PMC votes are cast.

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

Thanks,
Till & Bernd

Re: Can anyone help me understand the Mesos release model

[Till Toenshoff]

Alexander actually it spot on with his explanation. 

For the entire procedure, have a look at 
https://github.com/apache/mesos/blob/master/docs/release-guide.md 
.

At some point in a release, we do a cut and that is our first release 
candidate. From then on, the only things we put in are patches that are are 
fixing issues we found blocking the release. Those are cherry-picked and put 
onto some private release branch. Then we tag and push that tag, but not our 
internal branch to the public repo.


> On Dec 9, 2015, at 3:45 PM, Chengwei Yang  wrote:
> 
> On Wed, Dec 09, 2015 at 10:24:45PM +0800, zhiwei wrote:
>> Thanks, I see.
>> 
>> So push the tag to remote repository will be no code review, I think this
>> should be done by a committer who has the directly push permission.
> 
> Exactly, should we use branch to do stable release? which much easier to
> understand, code review(which patch will cherry-picked from master), and
> communication I think.
> 
> In addition, easier to maintain such a long release chain, rc1..rcN and bug 
> fix
> release for stable version, e.g. 0.2x.x
> 
> Just my 2 cents :-)
> 
> -- 
> Thanks,
> Chengwei
> 
>> 
>> On Wed, Dec 9, 2015 at 9:29 PM, Alexander Rojas 
>> wrote:
>> 
>>> Hi Zhiweik,
>>> 
>>> Alex
>>> 
>>> Best,
>>> 
>>> Alexander Rojas
>>> 
 On 09 Dec 2015, at 11:49, zhiwei  wrote:
 
 Hi all,
 
 I'm confused with the Mesos release model.
 
 Can anyone tell me when and how to create a release tag?
 
 Take 0.26.0 release tags as example:
 
 I found that the commit history of tag 0.26.0-rc1 and branch master
>>> become
 different since commit *2da4db5*, but the HEAD of tag 0.26.0-rc1 is
 *9965e96*.
 
 So can I say that the tag 0.26.0-rc1 was created at commit *2da4db5*,
>>> then
 pick up the commits between *2da4db5  *and *9965e96* on master branch?
 
 When and how to create 0.26.0-rc2? It seems that it has followed the same
 rules as create tag 0.26.0-rc1.
 
 For 0.26.0-rc3 and 0.26.0-rc4, I can see that 0.26.0-rc3 was created base
 on 0.26.0-rc2 and pick up some commits from master branch, 0.26.0-rc4 was
 created base on 0.26.0-rc3 and pick up some commits from master branch.
 
 
 There is a patch:
   Updated upgrade documentation with changes in NetworkInfo protobuf.
 
   Review: https://reviews.apache.org/r/40238
 
 It's has a different commit id in master, 0.26.0-rc1 and 0.26-rc2, but
>>> has
 a same commit id in 0.26.0-rc2, 0.26.0-rc3 and 0.26.0-rc4. Is someone
 manually pick up this patch from master to 0.26.0-rc1 and 0.26.0-rc2?
>>> 
>>> 

[VOTE] Release Apache Mesos 0.26.0 (rc4)

[Till Toenshoff]

Hi friends,

we had noticed some discrepancies between the V0 API and the V1 API,
hence we had to create a new release candidate even after the voting of
0.26.0-rc3 had officially ended. Sorry for that!

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

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.0-rc4


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.26.0-rc4/mesos-0.26.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-1093

Please vote on releasing this package as Apache Mesos 0.26.0!

The vote is open until Fri Dec 11 04:50:51 CET 2015 and passes if a majority of 
at least 3 +1 PMC votes are cast.

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

Thanks,
Bernd & Till

[VOTE] Release Apache Mesos 0.26.0 (rc3)

[Till Toenshoff]

Hi friends,

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

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.0-rc3


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

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

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

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.26.0-rc3/mesos-0.26.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-1091

Please vote on releasing this package as Apache Mesos 0.26.0!

The vote is open until Fri Dec  4 19:00:35 CET 2015 and passes if a majority of 
at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.26.0
[ ] -1 Do not release this package because …

Thanks,
Bernd & Till

Re: can anyone shepherd MESOS-3725

[Till Toenshoff]

Done - sry for not noting your request any earlier.

> On Nov 19, 2015, at 1:46 AM, James Peach  wrote:
> 
> Hi all,
> 
> Can anyone shepherd https://issues.apache.org/jira/browse/MESOS-3725?
> 
> thanks!
> 
> 

[VOTE] Release Apache Mesos 0.26.0 (rc1)

[Till Toenshoff]

Hi friends,

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


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


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

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

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

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

Please vote on releasing this package as Apache Mesos 0.26.0!

The vote is open until Sun Nov 15 20:13:46 CET 2015 and passes if a majority of 
at least 3 +1 PMC votes are cast.

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

Thanks,
Bernd & Till 

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

[Till Toenshoff]

+1 in general for this proposal.

Using JIRA for tracking TODO’s is great, especially for things like deprecation 
over/at releases. I am however unsure if *all* TODOs need to have a ticket 
assigned, so that is a detail we may want to discuss as well?

> On Nov 9, 2015, at 9:55 AM, Alex Clemmer  wrote:
> 
> I like this proposal a lot, as I often end up making a point to
> mention the MESOS- number in the comment anyway. I would rather
> have the format `TODO(MESOS-XXX)` though, because (1) the JIRA should
> capture the reporter as well as the assignee, and (2) it's not
> immediately clear from the structure that the name should be the
> reporter and not, say, the assignee.
> 
> On Sat, Nov 7, 2015 at 8:50 PM, Kapil Arya  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
> 
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

Welcome Kapil as Mesos committer and PMC member!

[Till Toenshoff]

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: Towards Mesos release 0.26.0

[Till Toenshoff]

As announced, we will be cutting the next release tomorrow, 6th of November. 

We currently have 130 blockers (as shown at 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12327111 
).

If you have any blocking issues assigned to yourself or if you are shepherding 
any of those, please make sure you update the target version unless you 
*really* want to block the 0.26 release. A quick fly-over seemed to suggest 
that only one of those actually should block 0.26; MESOS-2864 which will likely 
get solved today / tomorrow (thanks Vinod!).

Please answer this mail if you think your issues should be blocking the 
release, otherwise we will go ahead and move all those 129 issues to the next 
release.

Thanks for your help!
Till

> On Oct 19, 2015, at 3:44 PM, Bernd Mathiske  wrote:
> 
> Dear Mesos fans,
> 
> this is the tracking ticket for the upcoming next Mesos release.
> 
> https://issues.apache.org/jira/browse/MESOS-3758 
> 
> 
> Please read the ticket’s description for further instructions and tips on how 
> to get features and other improvements included.
> 
> The release managers will be Till and Bernd. If you have any questions, don’t 
> hesitate to post them here or contact us directly:
> 
> {till, bernd}mesosphere.io
> 
> We aim at making the first cut with a tag around November 6 and at finalizing 
> the release before November 17.
> 
> Best greetings,
> 
> Till and Bernd
> 

Re: Volunteer for next release

[Till Toenshoff]

That is awesome Joris - thanks a bunch :)

> On Oct 1, 2015, at 6:05 PM, Joris Van Remoortere <jo...@mesosphere.io> wrote:
> 
> +1 I can help triage with you :-)
> 
> On Thu, Oct 1, 2015 at 1:44 AM, Till Toenshoff <toensh...@me.com> wrote:
> 
>> Hi folks,
>> 
>> Bernd and I would like to volunteer for managing the next release 0.26.
>> 
>> The scope and ETA of 0.26 will be discussed today at the Mesos community
>> sync - hence more details on this will follow shortly.
>> 
>> Thanks,
>> Bernd and Till
>> 
>> 
>> 

Volunteer for next release

[Till Toenshoff]

Hi folks,

Bernd and I would like to volunteer for managing the next release 0.26.

The scope and ETA of 0.26 will be discussed today at the Mesos community sync - 
hence more details on this will follow shortly.

Thanks,
Bernd and Till

Re: Would like to be added as a contributor

[Till Toenshoff]

Hey Yong,

added you as a contributor.

Till


 On Aug 16, 2015, at 7:53 AM, Yong Feng fengyong...@gmail.com wrote:
 
 Forget to mention, my JIRA ID is luckyfengyong
 
 Thanks,
 
 Yong
 
 On Sat, Aug 15, 2015 at 10:25 AM, Yong Feng fengyong...@gmail.com wrote:
 
 Hi Team,
 
 I would like to be added as a contributor for future contribution to
 Mesos. Please give a help.
 
 Thanks,
 
 Yong
 

Re: Request to be added to contributors list

[Till Toenshoff]

Hey Chen,

I have added you as a contributor to our JIRA roles, you should be able to 
assign issues to yourself now.

Till

 On Jun 25, 2015, at 7:58 AM, zhiwei zhiw...@gmail.com wrote:
 
 Hi,
 
 I had created an issue and want to assign to myself, can anyone help
 adding me to the contributors list?
 
 Thanks.

Re: Style guide for std::move

[Till Toenshoff]

+1 for 1. “treat it like a deleted pointer”


 On Jun 12, 2015, at 4:21 PM, Alexander Rojas alexan...@mesosphere.io wrote:
 
 Hey guys, there have been questions on how to deal with std::move in the 
 code. Right now our style guide says nothing about it, but there is no 
 consensus in the reviews. The problem with std::move is that for all standard 
 library functions that accept rvalue references as parameters are guaranteed 
 to leave the moved object in a valid but unspecified state (see 
 http://en.cppreference.com/w/cpp/utility/move 
 http://en.cppreference.com/w/cpp/utility/move).
 
 The following are some ideas into how to deal with moved objects
 
 1. Treat std::move as a delete and stop using it after the move
   
   std::vectorint v{1, 2, 3, 4};
   ..,
   foo(std::move(v)); // Don’t use
 
 2. Always create explicitly an scope the object to be moved, with the first 
 line being the definition of the object to be moved, and the last line of the 
 scope the move itself.
 
   if (bar()) {
 {
   std::vectorint v{1, 2, 3};
   ….
   foo(std::move(v));
 }
   }
 
 3. Create a scope for the if no scope already exists following the rules of 
 2):
 
   if (bar()) {
 std::vectorint v{1, 2, 3};
 ….
 foo(std::move(v));
   }
   

Re: Mesos Jira workflow

[Till Toenshoff]

Very helpful Marco… I like the idea of tightening our JIRA workflow.

+1 removing “closed
+1 “reviewable” back to in progress — to me this is a very helpful signal for 
longer lasting comment addressing
+1 making sure that “accepted is the gatekeeper and includes assigning the 
maintainer as a default shepherd — should we even go as far as to prevent  
“assigning” issues that have not gotten “accepted” and “shepherd assigned” ?
+1 removing “reopened as it has no extra value for us

Resolving without accepting to me sounds like a shortcut that we might want to 
prevent as it could be a bad example?

 On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote:
 
 Hadn't realized that the mailing list forwarder would make the images 
 unavailable, apologies about that.
 
 I've created this Google Doc 
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
  which should be open and accessible.
 
 Again, please let me know if anyone feels strongly that we should keep the 
 current workflow.
 Thanks!
 
 Marco Massenzio
 Distributed Systems Engineer
 
 On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io 
 mailto:ma...@mesosphere.io wrote:
 Folks,
 
 Please take a look at MESOS-2806: in a nutshell, our current workflow is 
 rather convoluted and brings about a host of issues, when managing tasks' 
 status transitions (detailed in the Jira - see screenshots there).
 
 This is what it currently looks like:
 
 
 
 (spaghetti workflow? :)
 
 I would propose to simplify it to the following:
 
 
 
 I'm sure we can think up all sorts of corner cases, but I would submit that 
 simplicity would trump complexity and allow us to track progress (or lack 
 thereof) of stories/tasks/bugs in a much more punctual manner.
 
 Anyone against it?
 
 Marco Massenzio
 Distributed Systems Engineer
 

Re: [DISCUSS] Renaming Mesos Slave

[Till Toenshoff]

 1. Mesos Worker [node/host/machine]
 2. Mesos Worker [process]
 3. No, master/worker seems to address the issue with less changes.
 4. Begin using the new name ASAP, add a disambiguation to the docs, and 
 change old references over time.  Fixing the official name, even before 
 changes are in place, would be a good first step.

+1

Re: Let mesos to run on arm64 servers

[Till Toenshoff]

Hey Robin,

thanks for your patches, we definitely are interested in getting Mesos fully 
running on the ARM platform - so your work is highly welcome.

In a long run, we are hoping to entirely get rid of bundling those dependencies 
with Mesos. One question that popped up immediately; did you also try to get 
those patches submitted upstream into the glog, libev and protobuf?

Thanks again!
Till


 On Jun 1, 2015, at 11:05 AM, Adam Bordelon a...@mesosphere.io wrote:
 
 Robin, thanks for your interest in compiling and running Mesos on arm64.
 I have added you as a JIRA contributor and assigned the JIRA to you.
 Let's try to find you a Shepherd who can review and commit these changes for 
 you.
 TimStClair and Till have been involved in previous ARM issues: MESOS-1693 
 https://issues.apache.org/jira/browse/MESOS-1693 and MESOS-2021 
 https://issues.apache.org/jira/browse/MESOS-2021/MESOS-2022 
 https://issues.apache.org/jira/browse/MESOS-2022
 
 On Mon, Jun 1, 2015 at 12:18 AM, Robin Dong robin.k.d...@gmail.com 
 mailto:robin.k.d...@gmail.com wrote:
 Hi, mesos committers:
 
 I am working on arm64(aarch64) server project and I find out mesos can't be
 build on arm64 environment. So I create a Jira issue
 https://issues.apache.org/jira/browse/MESOS-2786 
 https://issues.apache.org/jira/browse/MESOS-2786 and
 want to be assigned for this issue.
 
 I already commit two reviews for solve this issue:
 
 https://reviews.apache.org/r/34881/ https://reviews.apache.org/r/34881/
 https://reviews.apache.org/r/34882/ https://reviews.apache.org/r/34882/
 
 and could run mesos-master/mesos-slave on a arm64 server now.
 Future tests and patches will coming soon after.
 
 Glad to receive any suggestion.
 
 --
 --
 Best Regard
 Robin Dong
 

Re: Please add me to jira

[Till Toenshoff]

I have added you to the list of Mesos contributors - you should now be able to 
assign the ticket in question to yourself.

 On May 25, 2015, at 5:54 AM, baotiao baot...@gmail.com wrote:
 
 Hi guys
 
 I would like to solve the issue 2588, I have commented in the issue, so could 
 you add me to jira
 my jira username is  baotiao
 
 Thank you
 
 
 
 陈宗志
 
 Blog:baotiao.github.io
 
 
 
 

Re: Review Request 33058: Updated test-frameworks to support principal only credential.

[Till Toenshoff]

 On April 10, 2015, 10:15 a.m., Alexander Rojas wrote:
  I was just wondering, if the authentication can be done without a shared 
  secret, why is it needed after all?

While the default (CRAM MD5) authentication mechanism does rely on the plain 
secret on both ends, other authentication mechanisms (/modules) do not.


- Till


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


On April 10, 2015, 7:25 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33058/
 ---
 
 (Updated April 10, 2015, 7:25 a.m.)
 
 
 Review request for mesos, Adam B and Alexander Rojas.
 
 
 Bugs: MESOS-2608
 https://issues.apache.org/jira/browse/MESOS-2608
 
 
 Repository: mesos-incubating
 
 
 Description
 ---
 
 see summary.
 
 
 Diffs
 -
 
   src/examples/java/TestFramework.java 9e95369 
   src/examples/python/test_framework.py a179df5 
   src/examples/test_framework.cpp 9f4b53e 
 
 Diff: https://reviews.apache.org/r/33058/diff/
 
 
 Testing
 ---
 
 make check + functional testing using custom authentication modules not 
 relying on a shared secrets.
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 33257: Fixed recover tasks only by the intiated containerizer.

[Till Toenshoff]

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

Ship it!



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130628

Not sure what would be correct but I guess it would be right to use a 
lower-case d for docker in all comments. Right now we have both variants in 
this patch.



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130623

s/checkpoint/checkpoints/



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130624

s/docker/the docker/



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130631

Reference to temporary is going to be a nono :) - see  
https://reviews.apache.org/r/33271



src/slave/containerizer/docker.cpp
https://reviews.apache.org/r/33257/#comment130632

Why did you move this up?



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130630

s/Mesos/mesos/



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130629

s/docker/the docker/


- Till Toenshoff


On April 17, 2015, 7:07 p.m., Timothy Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33257/
 ---
 
 (Updated April 17, 2015, 7:07 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Ian Downes, Jie 
 Yu, and Till Toenshoff.
 
 
 Bugs: MESOS-2601
 https://issues.apache.org/jira/browse/MESOS-2601
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed recover tasks only by the intiated containerizer.
 Currently both mesos and docker containerizer recovers tasks that wasn't 
 started by themselves.
 The proposed fix is to record the intended containerizer in the checkpointed 
 executorInfo, and reuse that information on recover to know if the 
 containerizer should recover or not. We are free to modify the executorInfo 
 since it's not being used to relaunch any task.
 The external containerizer doesn't need to change since it is only recovering 
 containers that are returned by the containers script.
 
 
 Diffs
 -
 
   src/slave/containerizer/docker.hpp 6893684e6d199a5d69fc8bba8e60c4acaae9c3c9 
   src/slave/containerizer/docker.cpp f9fb07806e3b7d7d2afc1be3b8756eac23b32dcd 
   src/slave/containerizer/mesos/containerizer.cpp 
 e4136095fca55637864f495098189ab3ad8d8fe7 
   src/slave/slave.cpp a0595f93ce4720f5b9926326d01210460ccb0667 
   src/tests/containerizer_tests.cpp 5991aa628083dac7c5e8bf7ba297f4f9edeec05f 
   src/tests/docker_containerizer_tests.cpp 
 c772d4c836de18b0e87636cb42200356d24ec73d 
 
 Diff: https://reviews.apache.org/r/33257/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Timothy Chen
 

Re: Review Request 33257: Fixed recover tasks only by the intiated containerizer.

[Till Toenshoff]

 On April 18, 2015, 2:55 a.m., Till Toenshoff wrote:
 

One more tiny nit, the summary has a typo.


- Till


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


On April 17, 2015, 7:07 p.m., Timothy Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33257/
 ---
 
 (Updated April 17, 2015, 7:07 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Ian Downes, Jie 
 Yu, and Till Toenshoff.
 
 
 Bugs: MESOS-2601
 https://issues.apache.org/jira/browse/MESOS-2601
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed recover tasks only by the intiated containerizer.
 Currently both mesos and docker containerizer recovers tasks that wasn't 
 started by themselves.
 The proposed fix is to record the intended containerizer in the checkpointed 
 executorInfo, and reuse that information on recover to know if the 
 containerizer should recover or not. We are free to modify the executorInfo 
 since it's not being used to relaunch any task.
 The external containerizer doesn't need to change since it is only recovering 
 containers that are returned by the containers script.
 
 
 Diffs
 -
 
   src/slave/containerizer/docker.hpp 6893684e6d199a5d69fc8bba8e60c4acaae9c3c9 
   src/slave/containerizer/docker.cpp f9fb07806e3b7d7d2afc1be3b8756eac23b32dcd 
   src/slave/containerizer/mesos/containerizer.cpp 
 e4136095fca55637864f495098189ab3ad8d8fe7 
   src/slave/slave.cpp a0595f93ce4720f5b9926326d01210460ccb0667 
   src/tests/containerizer_tests.cpp 5991aa628083dac7c5e8bf7ba297f4f9edeec05f 
   src/tests/docker_containerizer_tests.cpp 
 c772d4c836de18b0e87636cb42200356d24ec73d 
 
 Diff: https://reviews.apache.org/r/33257/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Timothy Chen
 

Review Request 33331: Added file headers section to the C++ style guide.

[Till Toenshoff]

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

Review request for mesos.


Repository: mesos-incubating


Description
---

see summary.


Diffs
-

  docs/mesos-c++-style-guide.md de1b93e 

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


Testing
---

N/A


Thanks,

Till Toenshoff

Review Request 33330: Fixed C++ style guide formatting.

[Till Toenshoff]

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

Review request for mesos.


Repository: mesos-incubating


Description
---

Enables syntax highlighting in markdown viewers.


Diffs
-

  docs/mesos-c++-style-guide.md de1b93e 

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


Testing
---

N/A


Thanks,

Till Toenshoff

Re: Review Request 33331: Added file headers section to the C++ style guide.

[Till Toenshoff]

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

(Updated April 18, 2015, 1:34 a.m.)


Review request for mesos.


Repository: mesos-incubating


Description
---

see summary.


Diffs
-

  docs/mesos-c++-style-guide.md de1b93e 

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


Testing
---

N/A


Thanks,

Till Toenshoff

Re: Review Request 32058: Added protobuf-JSON validation

[Till Toenshoff]

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



3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp
https://reviews.apache.org/r/32058/#comment130182

Just as Vinod commented on the JIRA, we might want  to do that differently 
- e.g. by adding a factory.


- Till Toenshoff


On March 16, 2015, 8:02 p.m., Akanksha Agrawal wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32058/
 ---
 
 (Updated March 16, 2015, 8:02 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-1194
 https://issues.apache.org/jira/browse/MESOS-1194
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Added protobuf-JSON validation
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
 2c020d98b94995bce862ac3b9c173dd64ed1198d 
 
 Diff: https://reviews.apache.org/r/32058/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Akanksha Agrawal
 

Re: Review Request 33257: Fixed recover tasks only by the intiated containerizer.

[Till Toenshoff]

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



src/slave/slave.cpp
https://reviews.apache.org/r/33257/#comment130173

Kill this line.



src/slave/slave.cpp
https://reviews.apache.org/r/33257/#comment130165

Remove this line.



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130167

Could you add a comment and describe what this test does?



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130176

Move this down to when you need it.



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130175

Move this down to when you actually need it.



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130168

I am not sure this comment adds any value - we may just as well remove it, 
no?



src/tests/containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130174

Kill these.



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130166

Could you add a comment and describe what this test does?



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130178

Move this down to where you need it.



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130177

Move this down to where you need it.



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130179

Move this down to where you need it.



src/tests/docker_containerizer_tests.cpp
https://reviews.apache.org/r/33257/#comment130180

Move this down to where you need it.


- Till Toenshoff


On April 16, 2015, 7:10 a.m., Timothy Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33257/
 ---
 
 (Updated April 16, 2015, 7:10 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Ian Downes, Jie 
 Yu, and Till Toenshoff.
 
 
 Bugs: MESOS-2601
 https://issues.apache.org/jira/browse/MESOS-2601
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed recover tasks only by the intiated containerizer.
 Currently both mesos and docker containerizer recovers tasks that wasn't 
 started by themselves.
 The proposed fix is to record the intended containerizer in the checkpointed 
 executorInfo, and reuse that information on recover to know if the 
 containerizer should recover or not. We are free to modify the executorInfo 
 since it's not being used to relaunch any task.
 The external containerizer doesn't need to change since it is only recovering 
 containers that are returned by the containers script.
 
 
 Diffs
 -
 
   src/slave/containerizer/docker.cpp f9fb07806e3b7d7d2afc1be3b8756eac23b32dcd 
   src/slave/containerizer/mesos/containerizer.cpp 
 e4136095fca55637864f495098189ab3ad8d8fe7 
   src/slave/slave.cpp a0595f93ce4720f5b9926326d01210460ccb0667 
   src/tests/containerizer_tests.cpp 5991aa628083dac7c5e8bf7ba297f4f9edeec05f 
   src/tests/docker_containerizer_tests.cpp 
 c772d4c836de18b0e87636cb42200356d24ec73d 
 
 Diff: https://reviews.apache.org/r/33257/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Timothy Chen
 

Re: Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

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

(Updated April 14, 2015, 2:20 p.m.)


Review request for mesos, Adam B, Joris Van Remoortere, and switched to 
'mcypark'.


Changes
---

Addressed Kapil's comment.


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


Repository: mesos-incubating


Description
---

Removing the process from the header is much cleaner and also fixes the linked 
clang 3.4.2 JIRA. Apart from that moving, no code is changed.


Diffs (updated)
-

  src/Makefile.am d15a373 
  src/authentication/cram_md5/authenticatee.hpp 55fac68 
  src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

 On April 14, 2015, 7:22 p.m., Kapil Arya wrote:
  src/authentication/cram_md5/authenticatee.cpp, lines 46-47
  https://reviews.apache.org/r/32850/diff/3/?file=922370#file922370line46
 
  According to our style guide, this is okay but we keep seeing issues 
  being raised about this. Should we just update the style guide instead?

The styleguide is IMHO unclear on this case as it proposes similar examples but 
only being ok. Definitely a case for an update suggestion.


- Till


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


On April 14, 2015, 2:20 p.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32850/
 ---
 
 (Updated April 14, 2015, 2:20 p.m.)
 
 
 Review request for mesos, Adam B, Joris Van Remoortere, and switched to 
 'mcypark'.
 
 
 Bugs: MESOS-2584
 https://issues.apache.org/jira/browse/MESOS-2584
 
 
 Repository: mesos-incubating
 
 
 Description
 ---
 
 Removing the process from the header is much cleaner and also fixes the 
 linked clang 3.4.2 JIRA. Apart from that moving, no code is changed.
 
 
 Diffs
 -
 
   src/Makefile.am d15a373 
   src/authentication/cram_md5/authenticatee.hpp 55fac68 
   src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32850/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

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

(Updated April 15, 2015, 12:44 a.m.)


Review request for mesos, Adam B, Joris Van Remoortere, and switched to 
'mcypark'.


Changes
---

Addressed most of Alex's comments.


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


Repository: mesos-incubating


Description
---

Removing the process from the header is much cleaner and also fixes the linked 
clang 3.4.2 JIRA. Apart from that moving, no code is changed.


Diffs (updated)
-

  src/Makefile.am d15a373 
  src/authentication/cram_md5/authenticatee.hpp 55fac68 
  src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

 On April 14, 2015, 2:16 p.m., Alexander Rukletsov wrote:
  src/authentication/cram_md5/authenticatee.cpp, lines 46-47
  https://reviews.apache.org/r/32850/diff/3/?file=922370#file922370line46
 
  Let's move to newline to avoid jaggeddness. Btw, what does clang-format 
  suggest?
 
 Kapil Arya wrote:
 According to our style guide, this is okay but we keep seeing issues 
 being raised about this. Should we just update the style guide instead?
 
 Alexander Rukletsov wrote:
 I would like to have just one way of doing this. I think the one with 
 newline scales better.

This was exactly clang-format's suggestion. Raised 
https://issues.apache.org/jira/browse/MESOS-2618


- Till


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


On April 15, 2015, 12:44 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32850/
 ---
 
 (Updated April 15, 2015, 12:44 a.m.)
 
 
 Review request for mesos, Adam B, Joris Van Remoortere, and switched to 
 'mcypark'.
 
 
 Bugs: MESOS-2584
 https://issues.apache.org/jira/browse/MESOS-2584
 
 
 Repository: mesos-incubating
 
 
 Description
 ---
 
 Removing the process from the header is much cleaner and also fixes the 
 linked clang 3.4.2 JIRA. Apart from that moving, no code is changed.
 
 
 Diffs
 -
 
   src/Makefile.am d15a373 
   src/authentication/cram_md5/authenticatee.hpp 55fac68 
   src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32850/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

 On April 14, 2015, 2:16 p.m., Alexander Rukletsov wrote:
 

Thanks a bunch for your review Alex, much appreciated.


- Till


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


On April 15, 2015, 12:44 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32850/
 ---
 
 (Updated April 15, 2015, 12:44 a.m.)
 
 
 Review request for mesos, Adam B, Joris Van Remoortere, and switched to 
 'mcypark'.
 
 
 Bugs: MESOS-2584
 https://issues.apache.org/jira/browse/MESOS-2584
 
 
 Repository: mesos-incubating
 
 
 Description
 ---
 
 Removing the process from the header is much cleaner and also fixes the 
 linked clang 3.4.2 JIRA. Apart from that moving, no code is changed.
 
 
 Diffs
 -
 
   src/Makefile.am d15a373 
   src/authentication/cram_md5/authenticatee.hpp 55fac68 
   src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32850/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 30263: Added test for CRAM-MD5 support of SASL within configuration phase.

[Till Toenshoff]

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

(Updated April 15, 2015, 2:50 a.m.)


Review request for mesos, Alexander Rojas and Cody Maloney.


Changes
---

Fixed OSX distcheck issue.


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


Repository: mesos


Description
---

see summary


Diffs (updated)
-

  configure.ac 868c041 

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


Testing (updated)
---

make distcheck (with and without CRAM-MD5 installed, Linux  OSX)


Thanks,

Till Toenshoff

Re: Review Request 32536: Updated variable naming style.

[Till Toenshoff]

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

Ship it!


Thanks for bringing this up Alex - I find it very clear and helpful.

- Till Toenshoff


On March 26, 2015, 4:10 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32536/
 ---
 
 (Updated March 26, 2015, 4:10 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Ben Mahler, Michael Park, Niklas 
 Nielsen, and Timothy Chen.
 
 
 Repository: mesos-incubating
 
 
 Description
 ---
 
 Documents the patterns we use to name variables and function arguments in our 
 codebase.
 
 Leading underscores to avoid ambiguity.
 ===
 
 We use this pattern extensively in libprocess, stout and mesos, a few 
 examples below.
 
 * `stout/try.hpp:105`
 ```
 Try(State _state, T* _t = NULL, const std::string _message = )
   : state(_state), t(_t), message(_message) {}
 ```
 
 * `process/http.hpp:480`
 ```
   URL(const std::string _scheme,
   const std::string _domain,
   const uint16_t _port = 80,
   const std::string _path = /,
   const hashmapstd::string, std::string _query =
 (hashmapstd::string, std::string()),
   const Optionstd::string _fragment = None())
 : scheme(_scheme),
   domain(_domain),
   port(_port),
   path(_path),
   query(_query),
   fragment(_fragment) {}
 ```
 
 * `slave/containerizer/linux_launcher.cpp:56`
 ```
 LinuxLauncher::LinuxLauncher(
 const Flags _flags,
 int _namespaces,
 const string _hierarchy)
   : flags(_flags),
 namespaces(_namespaces),
 hierarchy(_hierarchy) {}
 ```
 
 Trailing undescores as prime symbols.
 =
 
 We use this pattern in the code, though not extensively. I would like to see 
 more pass-by-value instead of creating copies from a variable passed by const 
 reference.
 
 * `master.cpp:2942`
 ```
 // Create and add the slave id.
 SlaveInfo slaveInfo_ = slaveInfo;
 slaveInfo_.mutable_id()-CopyFrom(newSlaveId());
 ```
 
 * `slave.cpp:4180`
 ```
 ExecutorInfo executorInfo_ = executor-info;
 Resources resources = executorInfo_.resources();
 resources += taskInfo.resources();
 executorInfo_.mutable_resources()-CopyFrom(resources);
 ```
 
 * `status_update_manager.cpp:474`
 ```
 // Bounded exponential backoff.
 Duration duration_ =
 std::min(duration * 2, STATUS_UPDATE_RETRY_INTERVAL_MAX);
 ```
 
 * `containerizer/mesos/containerizer.cpp:109`
 ```
 // Modify the flags to include any changes to isolation.
 Flags flags_ = flags;
 flags_.isolation = isolation;
 ```
 
 Passing arguments by value.
 ===
 
 * `slave.cpp:2480`
 ```
 void Slave::statusUpdate(StatusUpdate update, const UPID pid)
 {
   ...
   // Set the source before forwarding the status update.
   update.mutable_status()-set_source(
   pid == UPID() ? TaskStatus::SOURCE_SLAVE : TaskStatus::SOURCE_EXECUTOR);
   ...
 }
 ```
 
 * `process/metrics/timer.hpp:103`
 ```
   static void _time(Time start, Timer that)
   {
 const Time stop = Clock::now();
 
 double value;
 
 process::internal::acquire(that.data-lock);
 {
   that.data-lastValue = T(stop - start).value();
   value = that.data-lastValue.get();
 }
 process::internal::release(that.data-lock);
 
 that.push(value);
   }
 ```
 
 
 Diffs
 -
 
   docs/mesos-c++-style-guide.md 439fe12 
 
 Diff: https://reviews.apache.org/r/32536/diff/
 
 
 Testing
 ---
 
 None (not a functional change).
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 32001: Required a period in trailing comments in the style guide.

[Till Toenshoff]

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



docs/mesos-c++-style-guide.md
https://reviews.apache.org/r/32001/#comment129761

I actually think that MPark's draft fits very well. 

My suggestion would be:
End each sentence within a comment with punctuation - this applies to 
incomplete sentences as well. Please note that we generally prefer periods.


- Till Toenshoff


On March 26, 2015, 1:08 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32001/
 ---
 
 (Updated March 26, 2015, 1:08 p.m.)
 
 
 Review request for mesos and Ben Mahler.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   docs/mesos-c++-style-guide.md 439fe12ad137c1bed3a21d5a097c60a48f10a4f9 
 
 Diff: https://reviews.apache.org/r/32001/diff/
 
 
 Testing
 ---
 
 None (not a functional change).
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 32749: Add -Wno-unused-local-typedef for clang 3.6

[Till Toenshoff]

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

Ship it!



configure.ac
https://reviews.apache.org/r/32749/#comment129646

This is a bit unusual. We haven't marked our branches that way so far but I 
kinda like it.


- Till Toenshoff


On April 13, 2015, 9:01 p.m., Cody Maloney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32749/
 ---
 
 (Updated April 13, 2015, 9:01 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2550
 https://issues.apache.org/jira/browse/MESOS-2550
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Add -Wno-unused-local-typedef for clang 3.6
 
 
 Diffs
 -
 
   configure.ac 868c0413a2e2307ae8ab2211f56874595759b139 
 
 Diff: https://reviews.apache.org/r/32749/diff/
 
 
 Testing
 ---
 
 For series:
 
 ../configure --disable-java --disable-python CC=clang CXX=clang++
 `make check` passed on ArchLinux with clang version 3.6 as host compiler. 
 CXXFLAGS contains the typedef. Didn't build without patches.
 `make check` on ArchLinux with GCC 4.9
 
 ../configure
 `make distcheck` on CentOS 7 (GCC 4.8)
 
 ../configure
 `make distcheck` with OS X (Clang 3.5). Verified no 
 '-Wno-unused-local-typedef'.
 
 
 Thanks,
 
 Cody Maloney
 

Re: Review Request 32748: libprocess: Add -Wno-unused-local-typedef for clang 3.6

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On April 13, 2015, 9:01 p.m., Cody Maloney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32748/
 ---
 
 (Updated April 13, 2015, 9:01 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2550
 https://issues.apache.org/jira/browse/MESOS-2550
 
 
 Repository: mesos
 
 
 Description
 ---
 
 libprocess: Add -Wno-unused-local-typedef for clang 3.6
 
 
 Diffs
 -
 
   3rdparty/libprocess/configure.ac a126ecfc5211710bc34690daaae65e6817beb222 
 
 Diff: https://reviews.apache.org/r/32748/diff/
 
 
 Testing
 ---
 
 See last in series: #32749
 
 
 Thanks,
 
 Cody Maloney
 

Re: Review Request 32747: libprocess: Place noreturn attribute correctly for C11

[Till Toenshoff]

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

Ship it!


Let's add to summary and/or description that we are targetting libev 
specifically with this patch.

- Till Toenshoff


On April 13, 2015, 9:01 p.m., Cody Maloney wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32747/
 ---
 
 (Updated April 13, 2015, 9:01 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2550
 https://issues.apache.org/jira/browse/MESOS-2550
 
 
 Repository: mesos
 
 
 Description
 ---
 
 libprocess: Place noreturn attribute correctly for C11
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/libev-4.15.patch 
 2b94532634bf4fb69523cdfa26254de6c537d689 
 
 Diff: https://reviews.apache.org/r/32747/diff/
 
 
 Testing
 ---
 
 See last in series: #32749
 
 
 Thanks,
 
 Cody Maloney
 

Re: Review Request 32995: Split up documentation for reporting bugs and submitting patches.

[Till Toenshoff]

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



docs/reporting-a-bug.md
https://reviews.apache.org/r/32995/#comment128919

...please review the Assign the JIRA issue to yourself before you start 
working on it.

Not sure if this sentence makes any sense as is.


- Till Toenshoff


On April 9, 2015, 12:30 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32995/
 ---
 
 (Updated April 9, 2015, 12:30 a.m.)
 
 
 Review request for mesos, Benjamin Hindman and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Developers guide was too generic, this splits up the documents to focus on 
 what the reader is interesting in doing.
 
 
 Diffs
 -
 
   docs/home.md 6ab61f85aa7d62e0f19267b886dffb4e0aa826ea 
   docs/mesos-developers-guide.md 6023f2cc4d37ecabc24699bef6bda32068e5b43d 
   docs/reporting-a-bug.md PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/32995/diff/
 
 
 Testing
 ---
 
 N/A
 
 
 Thanks,
 
 Ben Mahler
 

Re: Review Request 32967: Cleaned upstyle and comments in modules.

[Till Toenshoff]

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



include/mesos/module/authenticatee.hpp
https://reviews.apache.org/r/32967/#comment128913

Could you please make this {} without that space as suggested by the JIRA?



src/examples/test_isolator_module.cpp
https://reviews.apache.org/r/32967/#comment128912

Can you please reduce the change of the comment towards replacing 
testCpuIsolator with org_apache_mesos_TestCpuIsolator as described by Kapil 
on the JIRA?

My point here is that your other changes do not seem to add value or 
improve readablity.

Same with the others as well, thanks!


- Till Toenshoff


On April 8, 2015, 8:05 p.m., Aditi Dixit wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32967/
 ---
 
 (Updated April 8, 2015, 8:05 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Ben Mahler, Kapil Arya, and 
 Vinod Kone.
 
 
 Bugs: MESOS-2565
 https://issues.apache.org/jira/browse/MESOS-2565
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed minor style issues in modules and the misleading comments.
 
 
 Diffs
 -
 
   include/mesos/module/authenticatee.hpp 
 94de988d524d6390a9f59edbc61f1f7cae514efd 
   include/mesos/module/authenticator.hpp 
 6a83f17b76ab0bf7af8acd3ddb8044f1bdfa78c0 
   include/mesos/module/hook.hpp a474e2bd118a5451c0574e33e2cbe9d7d7e95fce 
   include/mesos/module/isolator.hpp 452ad318b9d5445860fa49bcdb933925d750f900 
   src/examples/test_anonymous_module.cpp 
 859f4e19e0d50794172af4cff708edf171e6d02f 
   src/examples/test_hook_module.cpp 47409cd4d02e238d1d182571d92019114662cd41 
   src/examples/test_isolator_module.cpp 
 2c303f5ff2f17d56a840a5e0108281873c17ce6a 
   src/examples/test_module.hpp 041570ef3af338bc51c3b3218c460cc8b3f4e4de 
 
 Diff: https://reviews.apache.org/r/32967/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Aditi Dixit
 

Re: Review Request 32999: Added a document for engineering principles and practices.

[Till Toenshoff]

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

Ship it!


This really is great Ben.


docs/home.md
https://reviews.apache.org/r/32999/#comment128924

Should the link have a trailing slash as the others do?


- Till Toenshoff


On April 9, 2015, 12:30 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32999/
 ---
 
 (Updated April 9, 2015, 12:30 a.m.)
 
 
 Review request for mesos, Adam B, Benjamin Hindman, Jie Yu, Niklas Nielsen, 
 and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Added a document for engineering principles and practices.
 
 
 Diffs
 -
 
   docs/engineering-principles-and-practices.md PRE-CREATION 
   docs/home.md 6ab61f85aa7d62e0f19267b886dffb4e0aa826ea 
 
 Diff: https://reviews.apache.org/r/32999/diff/
 
 
 Testing
 ---
 
 N/A
 
 
 Thanks,
 
 Ben Mahler
 

Review Request 32850: Moved cram-md5 authenticatee process definition into implementation file.

[Till Toenshoff]

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

Review request for mesos, Joris Van Remoortere and switched to 'mcypark'.


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


Repository: mesos-incubating


Description
---

Removing the process from the header is much cleaner and also fixes the linked 
clang 3.4.2 JIRA. Apart from that moving, no code is changed.

NOTE: This patch is mostly a proof of concept for validation and further 
research. There are more tests breaking as described in the JIRA and those 
might need some care as well, depending on our clang 3.4 support strategy.


Diffs
-

  src/Makefile.am 9c01f5d 
  src/authentication/cram_md5/authenticatee.hpp 55fac68 
  src/authentication/cram_md5/authenticatee.cpp PRE-CREATION 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 30032: Added support for cache control in libprocess when dealing with static files.

[Till Toenshoff]

 On March 26, 2015, 4:32 p.m., Alexander Rukletsov wrote:
  3rdparty/libprocess/src/process.cpp, line 6
  https://reviews.apache.org/r/30032/diff/4/?file=834184#file834184line6
 
  One thing captures my attention is how we include C headers. AFAIK, the 
  standard requires to include them like
  ```
  #include ctime
  #include climits
  #include cstdio
  ```
  and so on.
  
  Could you please create a cleanup newbie JIRA for this?
 
 Alexander Rojas wrote:
 Not very sure about that, what it does by using the c… versions of the 
 headers is to put its functions in the std namespace. Check the C++11 
 Standard annex *D.6 C standard library headers*:
 
  2 Every C header, each of which has a name of the form name.h, behaves 
 as if each name placed in the standard library namespace by the corresponding 
 cname header is placed within the global namespace scope. It is unspecified 
 whether these names are first declared or defined within namespace scope 
 (3.3.6) of the namespace std and are then injected into the global namespace 
 scope by explicit using-declarations (7.3.3).
 
  3 Example: The header cstdlib assuredly provides its declarations and 
 definitions within the namespace std. It may also provide these names within 
 the global namespace. The header stdlib.h assuredly provides the same 
 declarations and definitions within the global namespace, much as in the C 
 Standard. It may also provide these names within the namespace std. —end 
 example.
 
 
 As it reads, using functions from the `cname` versions of the `name.h` 
 headers, may or may not (stdlib implementation specific) require to add the 
 namespace std too all functions and structs provided by the header.

Seems we got three options here;
- start using the C++ wrappers and allowed for a smooth transition (file by 
file as needed/touched)
- - not sure what the implications here are from an optimizing (linker) point 
of view
- global cleanup and `std` namespace added everywhere
- stick with the C variants

May be worth a dev-list discussion?


- Till


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


On March 26, 2015, 9:53 a.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/30032/
 ---
 
 (Updated March 26, 2015, 9:53 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Michael Park, and Till Toenshoff.
 
 
 Bugs: mesos-708
 https://issues.apache.org/jira/browse/mesos-708
 
 
 Repository: mesos
 
 
 Description
 ---
 
 When serving a static file, libprocess returns the header `Last-Modified` 
 which is used by browsers to control Cache.
 When a http request arrives containing the header `If-Modified-Since`, a 
 response `304 Not Modified` is returned if the date in the request and the 
 modification time (as returned by doing `stat` in the file) coincide.
 Unit tests added.
 
 
 Diffs
 -
 
   3rdparty/libprocess/include/process/http.hpp 9cf05ac 
   3rdparty/libprocess/src/process.cpp 67b6b3b 
   3rdparty/libprocess/src/tests/process_tests.cpp 3bbfe0a 
 
 Diff: https://reviews.apache.org/r/30032/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

Re: Review Request 31267: Added a test allocator module.

[Till Toenshoff]

 On March 27, 2015, 4:36 p.m., Alexander Rojas wrote:
  src/tests/module.cpp, line 137
  https://reviews.apache.org/r/31267/diff/4-5/?file=903021#file903021line137
 
  You may need a `CHECK(modules != NULL)` or a log and return in the NULL 
  case?
 
 Alexander Rukletsov wrote:
 If you follow the invokation path, you'll see that modules is a stack 
 variable (see `initModules()`) and can't be null. I agree this is not clear 
 at the place where we use a pointer to it and may change in the future, but 
 this is more a general question about the design decision that should go to 
 @tillt. Pass by pointer was introduced in 
 Commit: 7ee3b7b672a4d8fee4fe4eb5f0aa2e7e3bf6b049
 Review: https://reviews.apache.org/r/31253
 Author: Till Toenshoff toensh...@me.com

We generally avoid references when mutating on the callee side - that is a 
style descision which came from google's guidelines if I am not mistaken; see 
e.g. 
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Function_Parameter_Ordering


- Till


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


On March 27, 2015, 4:26 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31267/
 ---
 
 (Updated March 27, 2015, 4:26 p.m.)
 
 
 Review request for mesos, Kapil Arya, Michael Park, and Niklas Nielsen.
 
 
 Bugs: MESOS-2160
 https://issues.apache.org/jira/browse/MESOS-2160
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The test allocator module is a built-in HierarchicalDRFAllocator put in a 
 module.
 
 NOTE: Here we add harness code to load the module, tests will be wired up 
 later in the patch stack.
 
 
 Diffs
 -
 
   src/Makefile.am 7a06c7028eca8164b1f5fdea6a7ecd37ee6826bb 
   src/examples/test_allocator_module.cpp PRE-CREATION 
   src/tests/module.hpp 65e567f21744d9a2b07b8680d45bcd1ea47f9508 
   src/tests/module.cpp b81144f56e94034feecf3a6a4992af078cf60a81 
 
 Diff: https://reviews.apache.org/r/31267/diff/
 
 
 Testing
 ---
 
 make check (Mac OS 10.9.5, CentOS 7.0)
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 31267: Added a test allocator module.

[Till Toenshoff]

 On March 27, 2015, 4:36 p.m., Alexander Rojas wrote:
  src/tests/module.cpp, line 137
  https://reviews.apache.org/r/31267/diff/4-5/?file=903021#file903021line137
 
  You may need a `CHECK(modules != NULL)` or a log and return in the NULL 
  case?
 
 Alexander Rukletsov wrote:
 If you follow the invokation path, you'll see that modules is a stack 
 variable (see `initModules()`) and can't be null. I agree this is not clear 
 at the place where we use a pointer to it and may change in the future, but 
 this is more a general question about the design decision that should go to 
 @tillt. Pass by pointer was introduced in 
 Commit: 7ee3b7b672a4d8fee4fe4eb5f0aa2e7e3bf6b049
 Review: https://reviews.apache.org/r/31253
 Author: Till Toenshoff toensh...@me.com
 
 Till Toenshoff wrote:
 We generally avoid references when mutating on the callee side - that is 
 a style descision which came from google's guidelines if I am not mistaken; 
 see e.g. 
 https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Function_Parameter_Ordering

Actually the above link just menions it briefly, the one Alex just pointed me 
to is much more explicit: 
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments


- Till


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


On March 27, 2015, 4:26 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31267/
 ---
 
 (Updated March 27, 2015, 4:26 p.m.)
 
 
 Review request for mesos, Kapil Arya, Michael Park, and Niklas Nielsen.
 
 
 Bugs: MESOS-2160
 https://issues.apache.org/jira/browse/MESOS-2160
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The test allocator module is a built-in HierarchicalDRFAllocator put in a 
 module.
 
 NOTE: Here we add harness code to load the module, tests will be wired up 
 later in the patch stack.
 
 
 Diffs
 -
 
   src/Makefile.am 7a06c7028eca8164b1f5fdea6a7ecd37ee6826bb 
   src/examples/test_allocator_module.cpp PRE-CREATION 
   src/tests/module.hpp 65e567f21744d9a2b07b8680d45bcd1ea47f9508 
   src/tests/module.cpp b81144f56e94034feecf3a6a4992af078cf60a81 
 
 Diff: https://reviews.apache.org/r/31267/diff/
 
 
 Testing
 ---
 
 make check (Mac OS 10.9.5, CentOS 7.0)
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 31267: Added a test allocator module.

[Till Toenshoff]

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

Ship it!



src/tests/module.cpp
https://reviews.apache.org/r/31267/#comment127331

Much better than the old variant - thanks for pointing this out!


- Till Toenshoff


On March 27, 2015, 4:26 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31267/
 ---
 
 (Updated March 27, 2015, 4:26 p.m.)
 
 
 Review request for mesos, Kapil Arya, Michael Park, and Niklas Nielsen.
 
 
 Bugs: MESOS-2160
 https://issues.apache.org/jira/browse/MESOS-2160
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The test allocator module is a built-in HierarchicalDRFAllocator put in a 
 module.
 
 NOTE: Here we add harness code to load the module, tests will be wired up 
 later in the patch stack.
 
 
 Diffs
 -
 
   src/Makefile.am 7a06c7028eca8164b1f5fdea6a7ecd37ee6826bb 
   src/examples/test_allocator_module.cpp PRE-CREATION 
   src/tests/module.hpp 65e567f21744d9a2b07b8680d45bcd1ea47f9508 
   src/tests/module.cpp b81144f56e94034feecf3a6a4992af078cf60a81 
 
 Diff: https://reviews.apache.org/r/31267/diff/
 
 
 Testing
 ---
 
 make check (Mac OS 10.9.5, CentOS 7.0)
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 31268: Wired up test allocator to allocator tests.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 27, 2015, 4:27 p.m., Alexander Rukletsov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31268/
 ---
 
 (Updated March 27, 2015, 4:27 p.m.)
 
 
 Review request for mesos, Kapil Arya, Michael Park, and Niklas Nielsen.
 
 
 Bugs: MESOS-2160
 https://issues.apache.org/jira/browse/MESOS-2160
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Same typed tests are used for built-in and modularized allocators.
 
 
 Diffs
 -
 
   src/tests/master_allocator_tests.cpp 
 03a1bb8c92b44bc1ad1b5f5cff8d1fb971df2302 
 
 Diff: https://reviews.apache.org/r/31268/diff/
 
 
 Testing
 ---
 
 make check (Mac OS 10.9.5, CentOS 7.0)
 
 
 Thanks,
 
 Alexander Rukletsov
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

 On March 27, 2015, 10:46 p.m., Adam B wrote:
  Fix looks good to me. Buildbot, please take another look. ;)
 
 Vinod Kone wrote:
 Can you or @till let me know what the race and temporal issue here was? 
 And how this fixes it?

There was one major problem in these lines:
```
// Start authentication.
const FutureOptionstring future = authenticator.get()-authenticate(from)
  .onAny(defer(self(), Self::_authenticate, pid, lambda::_1));
```

The returned future was destructed before the local reference (`future`) would 
even receive it.

On the left side, we have a const ref. On the right side, we have a temporal 
(returned by `authenticate`). This in itself is fine as the lifetime of the 
temporary will be extended by the lifetime of the reference. Trouble is that 
the expression `onAny` then gets called on a reference to a temporary and 
generates a reference to that on return. The returned reference will not extend 
the lifetime of the future. Now havoc breaks lose as we have a dangling 
reference.

The problem is not showing on all systems as they OS may not immediately reuse 
the destroyed objects' memory.

For the possible race - that actually was not really a race - my 
update-comment was misleading. It was the fact that I realized that an 
onAny/... assignment could immediately trigger a callback invocation. Our 
defer certainly delays the callback but I felt that it would look much 
cleaner if I made sure that the initializing of authenticating happened 
before assigning the callback.


- Till


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


On March 25, 2015, 11:35 p.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27760/
 ---
 
 (Updated March 25, 2015, 11:35 p.m.)
 
 
 Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
 
 
 Bugs: MESOS-2050
 https://issues.apache.org/jira/browse/MESOS-2050
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The initial design and implementation of the authenticator module interface 
 caused issues and was not optimal for heavy lifting setup of external 
 dependencies. By introducing a two fold design, this has been decoupled from 
 the authentication message processing. The new design also gets us back on 
 track to the goal of makeing SASL a soft dependency of mesos.
 
 
 Diffs
 -
 
   include/mesos/authentication/authenticator.hpp f66217a 
   src/authentication/cram_md5/authenticator.hpp c6f465f 
   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
   src/authentication/cram_md5/auxprop.hpp b894386 
   src/master/master.hpp 3c957ab 
   src/master/master.cpp dccd7c6 
   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
 
 Diff: https://reviews.apache.org/r/27760/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

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

(Updated March 28, 2015, 2:25 a.m.)


Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.


Changes
---

No changes, hoping to trigger review-bot.


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


Repository: mesos


Description
---

The initial design and implementation of the authenticator module interface 
caused issues and was not optimal for heavy lifting setup of external 
dependencies. By introducing a two fold design, this has been decoupled from 
the authentication message processing. The new design also gets us back on 
track to the goal of makeing SASL a soft dependency of mesos.


Diffs (updated)
-

  include/mesos/authentication/authenticator.hpp f66217a 
  src/authentication/cram_md5/authenticator.hpp c6f465f 
  src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
  src/authentication/cram_md5/auxprop.hpp b894386 
  src/master/master.hpp 3c957ab 
  src/master/master.cpp dccd7c6 
  src/tests/cram_md5_authentication_tests.cpp 92a89c5 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

 On March 27, 2015, 10:46 p.m., Adam B wrote:
  Fix looks good to me. Buildbot, please take another look. ;)
 
 Vinod Kone wrote:
 Can you or @till let me know what the race and temporal issue here was? 
 And how this fixes it?
 
 Till Toenshoff wrote:
 There was one major problem in these lines:
 ```
 // Start authentication.
 const FutureOptionstring future = 
 authenticator.get()-authenticate(from)
   .onAny(defer(self(), Self::_authenticate, pid, lambda::_1));
 ```
 
 The returned future was destructed before the local reference (`future`) 
 would even receive it.
 
 On the left side, we have a const ref. On the right side, we have a 
 temporal (returned by `authenticate`). This in itself is fine as the lifetime 
 of the temporary will be extended by the lifetime of the reference. Trouble 
 is that the expression `onAny` then gets called on a reference to a temporary 
 and generates a reference to that on return. The returned reference will not 
 extend the lifetime of the future. Now havoc breaks lose as we have a 
 dangling reference.
 
 The problem is not showing on all systems as they OS may not immediately 
 reuse the destroyed objects' memory.
 
 For the possible race - that actually was not really a race - my 
 update-comment was misleading. It was the fact that I realized that an 
 onAny/... assignment could immediately trigger a callback invocation. Our 
 defer certainly delays the callback but I felt that it would look much 
 cleaner if I made sure that the initializing of authenticating happened 
 before assigning the callback.

Let me correct myself here; onAny gets called on a temporary, generates a 
reference and that is then referenced by `future`.


- Till


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


On March 25, 2015, 11:35 p.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27760/
 ---
 
 (Updated March 25, 2015, 11:35 p.m.)
 
 
 Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
 
 
 Bugs: MESOS-2050
 https://issues.apache.org/jira/browse/MESOS-2050
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The initial design and implementation of the authenticator module interface 
 caused issues and was not optimal for heavy lifting setup of external 
 dependencies. By introducing a two fold design, this has been decoupled from 
 the authentication message processing. The new design also gets us back on 
 track to the goal of makeing SASL a soft dependency of mesos.
 
 
 Diffs
 -
 
   include/mesos/authentication/authenticator.hpp f66217a 
   src/authentication/cram_md5/authenticator.hpp c6f465f 
   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
   src/authentication/cram_md5/auxprop.hpp b894386 
   src/master/master.hpp 3c957ab 
   src/master/master.cpp dccd7c6 
   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
 
 Diff: https://reviews.apache.org/r/27760/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 31538: Added validations performed in the MesosExecutorDriver to the Slave.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 9, 2015, 11:09 a.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31538/
 ---
 
 (Updated March 9, 2015, 11:09 a.m.)
 
 
 Review request for mesos, Isabel Jimenez, Till Toenshoff, and Vinod Kone.
 
 
 Bugs: mesos-2291
 https://issues.apache.org/jira/browse/mesos-2291
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Copies validations made to the messages exchanged between the slave and the 
 `MesosExecutorDriver` and performed in the executor driver to the slave. This 
 is requiered since the new HTTP API will deprecate the executor driver.
 
 
 Diffs
 -
 
   src/exec/exec.cpp d678f0682d803b0b080c3a6c296067ac9ab5dbf8 
   src/slave/slave.cpp 364d911b086dfe1f15f76aa3888f99146aa8d876 
 
 Diff: https://reviews.apache.org/r/31538/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

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

[Till Toenshoff]

+1 binding - make check tested on: 
  - OSX 10.10.3 + gcc 4.9.2
  - OSX 10.10.3 + clang 3.5
  - Ubuntu 14.04 + gcc 4.4.7


 On Mar 18, 2015, at 8:52 PM, Niklas Nielsen nik...@mesosphere.io wrote:
 
 Hi all,
 
 Please vote on releasing the following candidate as Apache Mesos 0.22.0.
 
 
 0.22.0 includes the following:
 
 
 * Support for explicitly sending status updates acknowledgements from
  schedulers; refer to the upgrades document for upgrading schedulers.
 * Rate limiting slave removal, to safeguard against unforeseen bugs leading
 to
  widespread slave removal.
 * Disk quota isolation in Mesos containerizer; refer to the containerization
  documentation to enable disk quota monitoring and enforcement.
 * Support for module hooks in task launch sequence. Refer to the modules
  documentation for more information.
 * Anonymous modules: a new kind of module that does not receive any
 callbacks
  but coexists with its parent process.
 * New service discovery info in task info allows framework users to specify
  discoverability of tasks for external service discovery systems. Refer to
  the framework development guide for more information.
 * New '--external_log_file' flag to serve external logs through the Mesos
 web UI.
 * New '--gc_disk_headroom' flag to control maxmimum executor sandbox age.
 
 
 The CHANGELOG for the release is available at:
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.22.0-rc4
 
 
 The candidate for Mesos 0.22.0 release is available at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz
 
 The tag to be voted on is 0.22.0-rc4:
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.0-rc4
 
 The MD5 checksum of the tarball can be found at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.0.tar.gz.md5
 
 The signature of the tarball can be found at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.0-rc4/mesos-0.22.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-1048
 
 Please vote on releasing this package as Apache Mesos 0.22.0!
 
 The vote is open until Sat Mar 21 12:49:56 PDT 2015 and passes if a
 majority of at least 3 +1 PMC votes are cast.
 
 [ ] +1 Release this package as Apache Mesos 0.22.0
 [ ] -1 Do not release this package because ...
 
 Thanks,
 Niklas

Re: Review Request 32105: Added operator to stout.flags.

[Till Toenshoff]

 On March 25, 2015, 3:30 p.m., Michael Park wrote:
  3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp, lines 
  592-600
  https://reviews.apache.org/r/32105/diff/4/?file=897000#file897000line592
 
  How about breaking this up in order to avoid the ad-hoc `join` code?
  
  ```
  std::vectorstd::string flags;
  
  foreachvalue (const flags::Flags flag, _flags) {
const Optionstd::string value = flag.stringify(_flags);
if (value.isSome()) {
  flags.push_back(value.get());
}
  }
  
  return stream  join(,, flags);
  ```

THat is a good approach indeed. Wont look just as nice as your example as we 
need `key + '=' + '' + value + ''` , not just the value.


- Till


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


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32105/
 ---
 
 (Updated March 17, 2015, 12:25 a.m.)
 
 
 Review request for mesos.
 
 
 Bugs: Mesos-2323
 https://issues.apache.org/jira/browse/Mesos-2323
 
 
 Repository: mesos
 
 
 Description
 ---
 
 see summary
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
 aedb6ab30d929b81f55270612e76009bd7850daa 
 
 Diff: https://reviews.apache.org/r/32105/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Joerg Schad
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

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

(Updated March 25, 2015, 11:35 p.m.)


Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.


Changes
---

Fixed possible race and reference to temporal issue (the latter triggered an 
ASF builtbot make check failure on AuthenticationTest.SchedulerFailover).


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


Repository: mesos


Description
---

The initial design and implementation of the authenticator module interface 
caused issues and was not optimal for heavy lifting setup of external 
dependencies. By introducing a two fold design, this has been decoupled from 
the authentication message processing. The new design also gets us back on 
track to the goal of makeing SASL a soft dependency of mesos.


Diffs (updated)
-

  include/mesos/authentication/authenticator.hpp f66217a 
  src/authentication/cram_md5/authenticator.hpp c6f465f 
  src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
  src/authentication/cram_md5/auxprop.hpp b894386 
  src/master/master.hpp 3c957ab 
  src/master/master.cpp dccd7c6 
  src/tests/cram_md5_authentication_tests.cpp 92a89c5 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 32105: Added operator to stout.flags.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 17, 2015, 12:25 a.m., Joerg Schad wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32105/
 ---
 
 (Updated March 17, 2015, 12:25 a.m.)
 
 
 Review request for mesos.
 
 
 Bugs: Mesos-2323
 https://issues.apache.org/jira/browse/Mesos-2323
 
 
 Repository: mesos
 
 
 Description
 ---
 
 see summary
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
 aedb6ab30d929b81f55270612e76009bd7850daa 
 
 Diff: https://reviews.apache.org/r/32105/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Joerg Schad
 

Re: Review Request 30931: Added flags to logs at master and slave startup.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 16, 2015, 3:20 p.m., Joerg Schad wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/30931/
 ---
 
 (Updated March 16, 2015, 3:20 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2323
 https://issues.apache.org/jira/browse/MESOS-2323
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Added flags to logs at master and slave startup.
 
 
 Diffs
 -
 
   src/master/master.cpp dccd7c635da4b7031cd109bd84e7f17b31777ef1 
   src/slave/slave.cpp 0f99e4efb8fa2b96f120a3e49191158ca0364c06 
 
 Diff: https://reviews.apache.org/r/30931/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Joerg Schad
 

Re: Review Request 32198: Added a not equal operator for json objects.

[Till Toenshoff]

 On March 18, 2015, 5:36 p.m., Till Toenshoff wrote:
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp, lines 252-263
  https://reviews.apache.org/r/32198/diff/1/?file=898923#file898923line252
 
  Right now, these tests appear a bit random to me. Can you explain the 
  idea on why you came up with 8 tests?
  
  Maybe we could have some simple top-level object comparison first 
  `{foo: foo} != {bar: bar}` to be more explicit. Then one or two 
  deeper nested variants?
 
 Alexander Rojas wrote:
 It is not random, it just has one element of each type you can have as a 
 json, an array, a boolean, a null a string and a nested object. It just 
 ensures that the visitor will call all of its methods in turn.

Thanks for clarifying.


- Till


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


On March 23, 2015, 2:19 p.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32198/
 ---
 
 (Updated March 23, 2015, 2:19 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Niklas Nielsen, and Till Toenshoff.
 
 
 Bugs: MESOS-2510
 https://issues.apache.org/jira/browse/MESOS-2510
 
 
 Repository: mesos
 
 
 Description
 ---
 
 For consistency, adds a non equal operator to the json objects.
 
 It also adds tests to the equality operators.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
 334c898906018be6e663f53815abbe047806b95c 
   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
 f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
 
 Diff: https://reviews.apache.org/r/32198/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

Re: Review Request 32198: Added a not equal operator for json objects.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 23, 2015, 2:19 p.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32198/
 ---
 
 (Updated March 23, 2015, 2:19 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Niklas Nielsen, and Till Toenshoff.
 
 
 Bugs: MESOS-2510
 https://issues.apache.org/jira/browse/MESOS-2510
 
 
 Repository: mesos
 
 
 Description
 ---
 
 For consistency, adds a non equal operator to the json objects.
 
 It also adds tests to the equality operators.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
 334c898906018be6e663f53815abbe047806b95c 
   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
 f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
 
 Diff: https://reviews.apache.org/r/32198/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

Re: Review Request 32403: Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 23, 2015, 6:03 p.m., Joerg Schad wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32403/
 ---
 
 (Updated March 23, 2015, 6:03 p.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2530
 https://issues.apache.org/jira/browse/MESOS-2530
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Fixed Alloc/Dealloc mismatch in OsSendfileTest.sendfile.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/tests/os/sendfile_tests.cpp 
 2af4dca1559e9edd1e0a4acee9844adacc724a49 
 
 Diff: https://reviews.apache.org/r/32403/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Joerg Schad
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/master/master.cpp, lines 3858-3861
  https://reviews.apache.org/r/27760/diff/23/?file=890575#file890575line3858
 
  Send a FrameworkError message (instead of AuthenticationError) here to 
  avoid retries?
 
 Till Toenshoff wrote:
 The `AuthenticationErrorMessage` is sent to the AuthenticateeProcess, not 
 the process to be authenticated (slave / framework). The behaviour on this 
 specific event (failed to init the authenticator) has not changed. I believe 
 we commented on this before and agreed to come up with a cleanup on 
 authentication result handling later, in a follow-up-patch. Do I remember 
 correctly here?
 
 Adam B wrote:
 Let's create a separate JIRA so that authenticatees (or the owning 
 framework/slave) can know from the authentication response (error/failed) 
 whether to quit or retry.

https://issues.apache.org/jira/browse/MESOS-2482. Marking this as fixed for now.


- Till


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


On March 20, 2015, 10:21 p.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27760/
 ---
 
 (Updated March 20, 2015, 10:21 p.m.)
 
 
 Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
 
 
 Bugs: MESOS-2050
 https://issues.apache.org/jira/browse/MESOS-2050
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The initial design and implementation of the authenticator module interface 
 caused issues and was not optimal for heavy lifting setup of external 
 dependencies. By introducing a two fold design, this has been decoupled from 
 the authentication message processing. The new design also gets us back on 
 track to the goal of makeing SASL a soft dependency of mesos.
 
 
 Diffs
 -
 
   include/mesos/authentication/authenticator.hpp f66217a 
   src/authentication/cram_md5/authenticator.hpp c6f465f 
   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
   src/authentication/cram_md5/auxprop.hpp b894386 
   src/master/master.hpp 3c957ab 
   src/master/master.cpp dccd7c6 
   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
 
 Diff: https://reviews.apache.org/r/27760/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

 On March 16, 2015, 9:41 p.m., Vinod Kone wrote:
  src/authentication/cram_md5/authenticator.cpp, lines 552-554
  https://reviews.apache.org/r/27760/diff/24/?file=891848#file891848line552
 
  Why is this an initialization error? The previous semantics are that if 
  credentials were not provided, authentication was simply refused. Now 
  because of this change, we are sending an AuthenticationErrorMessage in 
  Master::authenticate().

Yes, thanks for pointing this out.


 On March 16, 2015, 9:41 p.m., Vinod Kone wrote:
  src/master/master.cpp, lines 3844-3845
  https://reviews.apache.org/r/27760/diff/24/?file=891851#file891851line3844
 
  see my comments in CramMD5Authenticator::initialize(). No credentials 
  didn't lead to AuthenticationErrorMessage before but rather refusal of 
  authentication.

I am now adding a warning log into the authenticator to make sure the user gets 
a hint on that;
```
LOG(WARNING)  No credentials provided, authentication requests will be 
  refused.;

```


- Till


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


On March 12, 2015, 12:32 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27760/
 ---
 
 (Updated March 12, 2015, 12:32 a.m.)
 
 
 Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
 
 
 Bugs: MESOS-2050
 https://issues.apache.org/jira/browse/MESOS-2050
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The initial design and implementation of the authenticator module interface 
 caused issues and was not optimal for heavy lifting setup of external 
 dependencies. By introducing a two fold design, this has been decoupled from 
 the authentication message processing. The new design also gets us back on 
 track to the goal of makeing SASL a soft dependency of mesos.
 
 
 Diffs
 -
 
   include/mesos/authentication/authenticator.hpp f66217a 
   src/authentication/cram_md5/authenticator.hpp c6f465f 
   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
   src/authentication/cram_md5/auxprop.hpp b894386 
   src/master/master.hpp 3c957ab 
   src/master/master.cpp dccd7c6 
   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
 
 Diff: https://reviews.apache.org/r/27760/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff
 

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

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

(Updated March 20, 2015, 10:21 p.m.)


Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.


Changes
---

Adressed Vinods comments.


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


Repository: mesos


Description
---

The initial design and implementation of the authenticator module interface 
caused issues and was not optimal for heavy lifting setup of external 
dependencies. By introducing a two fold design, this has been decoupled from 
the authentication message processing. The new design also gets us back on 
track to the goal of makeing SASL a soft dependency of mesos.


Diffs (updated)
-

  include/mesos/authentication/authenticator.hpp f66217a 
  src/authentication/cram_md5/authenticator.hpp c6f465f 
  src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
  src/authentication/cram_md5/auxprop.hpp b894386 
  src/master/master.hpp 3c957ab 
  src/master/master.cpp dccd7c6 
  src/tests/cram_md5_authentication_tests.cpp 92a89c5 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 32198: Added a not equal operator for json objects.

[Till Toenshoff]

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



3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp
https://reviews.apache.org/r/32198/#comment124618

Right now, these tests appear a bit random to me. Can you explain the idea 
on why you came up with 8 tests?

Maybe we could have some simple top-level object comparison first `{foo: 
foo} != {bar: bar}` to be more explicit. Then one or two deeper nested 
variants?


- Till Toenshoff


On March 18, 2015, 10:46 a.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32198/
 ---
 
 (Updated March 18, 2015, 10:46 a.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Niklas Nielsen, and Till Toenshoff.
 
 
 Bugs: MESOS-2510
 https://issues.apache.org/jira/browse/MESOS-2510
 
 
 Repository: mesos
 
 
 Description
 ---
 
 For consistency, adds a non equal operator to the json objects.
 
 It also adds tests to the equality operators.
 
 
 Diffs
 -
 
   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
 334c898906018be6e663f53815abbe047806b95c 
   3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
 f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 
 
 Diff: https://reviews.apache.org/r/32198/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

Re: Review Request 31539: Remove the checkpoint variable entirely from slave/flags.hpp.

[Till Toenshoff]

 On March 15, 2015, 9:03 a.m., Adam B wrote:
  src/tests/master_tests.cpp, line 1928
  https://reviews.apache.org/r/31539/diff/5/?file=894989#file894989line1928
 
  Not yours, but could you help out our style update push and s/ // 
  in code next to your changes (not necessarily the entire file)?
 
 Joerg Schad wrote:
 As seemingly there is some discussion whether to do such style fixes or 
 not, I will provide another Patch/Jira to fix   -  for all tests.

I would suggest to not do that. Let me try to explain:

This particual RR is rather unusual in that it touches many files. In october 
of last year, we reached a consesus for style debt fixes; we said that it would 
be nice if all files touched would also get this style update (dev-list: `Large 
changes on the codebase due to MESOS-1872`).

A. Lets not bundle any style debt fixes with this one at all as it is atypical 
and not covered by our consesus.

B. Lets make two RRs out of it, first fixing all sharp bracket whitspaces on 
the files to be touched by this RR. Then base this RR on those style fixes. 
This will still allow quick and easy reviews but also get a big pile of style 
debt fixes merged into the project.


- Till


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


On March 16, 2015, 10:07 a.m., Joerg Schad wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31539/
 ---
 
 (Updated March 16, 2015, 10:07 a.m.)
 
 
 Review request for mesos, Adam B, Cody Maloney, and Till Toenshoff.
 
 
 Bugs: MESOS-2375
 https://issues.apache.org/jira/browse/MESOS-2375
 
 
 Repository: mesos
 
 
 Description
 ---
 
 As a number of tests rely on the checkpointing flag to be false, a few tests 
 had to be adapted.
 Removed the following test as the tested logic is specific to (old) 
 non-checkpointing slaves:
 SlaveRecoveryTest.NonCheckpointingSlave:
This test checks whether a non-checkpointing slave is not scheduled to a 
 checkpointing framework.   
It can be removed as all slaves are checkpointing slaves.
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 9df972d750ce1e4a81d2e96cc508d6f83cad2fc8 
   src/slave/flags.hpp 56b25caf3901b38bdecb50310e8bcae0b114efa8 
   src/slave/slave.cpp 0f99e4efb8fa2b96f120a3e49191158ca0364c06 
   src/tests/disk_quota_tests.cpp 9c3a8815c3478535b72888c296a4aa5cda341ba3 
   src/tests/docker_containerizer_tests.cpp 
 06cd3d89ecbaaac17ae6970604b21fbe29f6e887 
   src/tests/fault_tolerance_tests.cpp 
 9ac75b1f601e14a3d3d117775f37a4a48b291dc6 
   src/tests/gc_tests.cpp deaa6b1b6c32ae6d153229248d7d4f57caa0ebcf 
   src/tests/master_allocator_tests.cpp 
 a432d0207e1a92532a495bf9ad2826414ee4f6f0 
   src/tests/master_authorization_tests.cpp 
 ff706ed6f8537207b30a548b0ce2121c5df71ab9 
   src/tests/master_tests.cpp e69348be676a80017062e3abbd15b8008a6009d7 
   src/tests/master_validation_tests.cpp 
 c8742928a4e93e86ccd0f5a39856a65cfe8eb74f 
   src/tests/mesos.cpp c8f43d21b214e75eaac2870cbdf4f03fd18707d1 
   src/tests/partition_tests.cpp bb96aed37861867fbde68445016f0c6e039f3fb4 
   src/tests/persistent_volume_tests.cpp 
 b617117ade4b487cc06002cfeca76a0486833b20 
   src/tests/reconciliation_tests.cpp acd70021574b05ab23872add5bdfa4a46b7dfc51 
   src/tests/slave_recovery_tests.cpp 53adae0118a26e6d25a9ff20c6374cc8e73275b1 
   src/tests/status_update_manager_tests.cpp 
 216a22e9f292b4141c8b966dad0f25dbd791c025 
 
 Diff: https://reviews.apache.org/r/31539/diff/
 
 
 Testing
 ---
 
 make check GTEST_BREAK_ON_FAILURE=1 GTEST_SHUFFLE=1 GTEST_REPEAT=50 on OSX 
 (had to exclude some known flaky tests under OSX)
 
 
 Thanks,
 
 Joerg Schad
 

Re: Review Request 32034: Fixed unused comparisons on the == operator for TaskStatus.

[Till Toenshoff]

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

Ship it!


Ship It!

- Till Toenshoff


On March 13, 2015, 10:56 a.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32034/
 ---
 
 (Updated March 13, 2015, 10:56 a.m.)
 
 
 Review request for mesos and Till Toenshoff.
 
 
 Bugs: MESOS-2494
 https://issues.apache.org/jira/browse/MESOS-2494
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Commit 8385bba added a comparison operator which added a ; instead of  
 ignoring most of the expression creating an expression result unused when 
 compiling with clang.
 
 
 Diffs
 -
 
   src/common/type_utils.cpp c9469912c420f9b1c01b0a3827867245f4d24dfd 
 
 Diff: https://reviews.apache.org/r/32034/diff/
 
 
 Testing
 ---
 
 make  make check
 
 
 Thanks,
 
 Alexander Rojas
 

Review Request 31960: Added concurrency protection within the SASL auxprop plugin code.

[Till Toenshoff]

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

Review request for mesos, Adam B and Vinod Kone.


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


Repository: mesos-incubating


Description
---

see summary.


Diffs
-

  src/authentication/cram_md5/auxprop.hpp b894386 
  src/authentication/cram_md5/auxprop.cpp cf503a2 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

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

(Updated March 12, 2015, 12:32 a.m.)


Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.


Changes
---

Split review into dependency chain and addressed a couple of comments.


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


Repository: mesos


Description
---

The initial design and implementation of the authenticator module interface 
caused issues and was not optimal for heavy lifting setup of external 
dependencies. By introducing a two fold design, this has been decoupled from 
the authentication message processing. The new design also gets us back on 
track to the goal of makeing SASL a soft dependency of mesos.


Diffs (updated)
-

  include/mesos/authentication/authenticator.hpp f66217a 
  src/authentication/cram_md5/authenticator.hpp c6f465f 
  src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
  src/authentication/cram_md5/auxprop.hpp b894386 
  src/master/master.hpp 3c957ab 
  src/master/master.cpp dccd7c6 
  src/tests/cram_md5_authentication_tests.cpp 92a89c5 

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 27760: Revised authenticator interface to allow for two fold implementations.

[Till Toenshoff]

 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/authentication/cram_md5/authenticator.hpp, lines 79-82
  https://reviews.apache.org/r/27760/diff/23/?file=890570#file890570line79
 
  i wish this move was done in its own review (w/o functional changes), 
  so that we can commit it right away.

Fixed that, now we got https://reviews.apache.org/r/31961/


 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/authentication/cram_md5/auxprop.hpp, line 54
  https://reviews.apache.org/r/27760/diff/23/?file=890572#file890572line54
 
  lets do this lock protection in its own dependent review.

Fixed that, now we got https://reviews.apache.org/r/31960/


 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/master/master.hpp, lines 668-670
  https://reviews.apache.org/r/27760/diff/23/?file=890574#file890574line668
 
  Can you comment on what the outer and inner future signifies?

We got rid of them :)


 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/master/master.cpp, lines 3888-3889
  https://reviews.apache.org/r/27760/diff/23/?file=890575#file890575line3888
 
  Per our offline discussion, I think we can get rid of this promise 
  altogether now. please send a dependent review for that.

Fixed that, we now got https://reviews.apache.org/r/31957/


 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/master/master.cpp, line 3887
  https://reviews.apache.org/r/27760/diff/23/?file=890575#file890575line3887
 
  authenticated successfully is confusing. do you mean completed 
  authentication process?

Fixed by removing out promise/future alltogether.


 On March 11, 2015, 9:42 p.m., Vinod Kone wrote:
  src/authentication/cram_md5/authenticator.cpp, lines 419-421
  https://reviews.apache.org/r/27760/diff/23/?file=890571#file890571line419
 
  looks like AuthenticatorSessionProcess already has an onDiscard handler 
  that transitions the innermost future to FAILED. Do we still need the 
  onDiscard handler here?

Yeah, I noticed that as well, now that I was re-re-refactoring things :) -- we 
got confused here, manifested in the previous update to this RR.


- Till


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


On March 12, 2015, 12:32 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/27760/
 ---
 
 (Updated March 12, 2015, 12:32 a.m.)
 
 
 Review request for mesos, Adam B, Kapil Arya, Niklas Nielsen, and Vinod Kone.
 
 
 Bugs: MESOS-2050
 https://issues.apache.org/jira/browse/MESOS-2050
 
 
 Repository: mesos
 
 
 Description
 ---
 
 The initial design and implementation of the authenticator module interface 
 caused issues and was not optimal for heavy lifting setup of external 
 dependencies. By introducing a two fold design, this has been decoupled from 
 the authentication message processing. The new design also gets us back on 
 track to the goal of makeing SASL a soft dependency of mesos.
 
 
 Diffs
 -
 
   include/mesos/authentication/authenticator.hpp f66217a 
   src/authentication/cram_md5/authenticator.hpp c6f465f 
   src/authentication/cram_md5/authenticator.cpp PRE-CREATION 
   src/authentication/cram_md5/auxprop.hpp b894386 
   src/master/master.hpp 3c957ab 
   src/master/master.cpp dccd7c6 
   src/tests/cram_md5_authentication_tests.cpp 92a89c5 
 
 Diff: https://reviews.apache.org/r/27760/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Till Toenshoff