Re: Authorization Logging

[Alexander Rojas]

This is a good question on where to do the audit, should it happen in the 
authorization module itself, or in the caller. It doesn’t help that you can 
authorize using approvers or the authorizer or the not so long ago introuced 
acceptors. There are also function wrappers that help to do so. 

The feeling we have had in the past is that the authorizer interface was 
created to accomodate the needs of the people writing authorization modules but 
no so much its use inside our code base. That’s why I’ve been working in a set 
of patches to try to clean up a little bit the code that calls authorization 
based on ideas from BenH https://reviews.apache.org/r/65311/ 
<https://reviews.apache.org/r/65311/> .

Reviews/comments always welcomed

Alexander Rojas
alexander.ro...@gmail.com




> On 28. Feb 2018, at 23:52, Benjamin Mahler <bmah...@apache.org> wrote:
> 
> When touching some code, I noticed that authorization logging is currently 
> done rather inconsistently across the call-sites and many cases do not log 
> the request:
> 
> $ grep -R -A 3 'LOG.*Authorizing' src
> 
> Should authorization logging be the concern of an authorizer implementation? 
> For audit purposes I could imagine this also being part of a separate log 
> that the authorizer maintains?
> 
> Ben

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

[Alexander Rojas]

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 <bev...@mesosphere.com> 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://issues.apache.org/jira/browse/MESOS-7748
> or https://issues.apache.org/jira/browse/MESOS-7800.
> 
> 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 memory issues tend to be most visible after a given
> process has been running for a long time, it would be great to
> have the option to enable heap tracking and profiling at runtime,
> without having to restart the process. (This ability could then
> be connected to a Mesos endpoint, similar to how we can adjust
> the log level at runtime)
> 
> The two production-quality memory allocators that have this
> ability currently seem to be tcmalloc and jemalloc. Of these,
> jemalloc does produce in our experience better and more
> detailed statistics.
> 
> 
> # What is the impact on users who do not need this feature?
> 
> Naturally, not every single user of Mesos will have a need
> for this feature. To ensure these users would not experience serious
> performance regressions as a result of this change, we conducted
> a preliminary set of benchmarks whose results are collected
> under https://issues.apache.org/jira/browse/MESOS-7876
> 
> It turns out that we could probably even expect a small speedup (1% - 5%)
> as a nice side-effect of this change.
> 
> Users who compile Mesos themselves would of course have the option
> to disable jemalloc at configuration time or replace it with their
> memory allocator of choice.
> 
> 
> 
> I'm looking forward to hear any thoughts and comments.
> 
> 
> Thanks,
> -- 
> Benno Evers
> Software Engineer, Mesosphere

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

[Alexander Rojas]

+1 (binding)

Ran manual tests in Fedora 25 and Ubuntu 17.04

Alexander Rojas
alexan...@mesosphere.io




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

Mesos 1.2.2 Release

[Alexander Rojas]

I’m planning to cut the 1.2.2 release on Friday July 28th, 2017 and have
voting start one the following Monday.

So far there are four issues open targeted for this release non of which 
is marked as a blocker for such release. 

If there are any other patches targeted for this release, please let me 
know.

For any backport patches, please update the CHANGELOG accordingly.

Best,

Alexander Rojas
alexan...@mesosphere.io

Re: Easing the Pain of Code Formatting in Mesos

[Alexander Rojas]

+1 It is always frustrating to rely in clang format to realize it generate the 
wrong style, even for old Mesos contributors

Alexander Rojas
alexan...@mesosphere.io




> On 15. Jun 2017, at 04:32, Michael Park <mp...@apache.org> wrote:
> 
> I'm increasingly hearing that many contributors who want to contribute to
> Mesos find that
> it's often difficult to do so. One of the big issues is due to our
> formatting rules which is not
> automated. As a result, we've had many reviews that are overwhelming in
> style comments
> with only a couple of comments on functionality.
> 
> This is very frustrating for contributors, and is also a large burden on
> the committers to
> remember, review and explain the formatting sections of the style guide.
> 
> I introduced *ClangFormat* a long time ago as our formatting tool, but it
> was only
> a supplementary tool since it didn't yet conform fully to the style guide.
> We've done a lot of
> work to narrow this gap and the gap is actually quite small at this point.
> However, the existence
> of such a gap is enough to stir discussions and render the tool useless for
> some people.
> 
> I think we should close this gap by adopting ClangFormat as our formatting
> guideline.
> 
> I don't have a fully fleshed out plan just yet. I'd like to push for this
> effort again,
> as I find it to be very important.
> 
> I'm just seeking for +1s if you'd like to see a fleshed out plan for this.
> 
> Thanks,
> 
> MPark

Use of ACLs.RegisterAgent.agent

[Alexander Rojas]

Hey guys,

We just noted that there was an error when the `RegisterAgent` act was 
introduced. Namely, its object field is listed as `agent` when by convention we 
have used plural, so it should be `agents`. This ACL hasn’t been part of any 
released version of Mesos, so if no one is using it I will try to push for a 
rename without going through any deprecation cycle.

The big question is if any of you are using this particular ACL in production 
right now?

Alexander Rojas
alexan...@mesosphere.io

Re: Custom Authentication

[Alexander Rojas]

Hi Joao,

Mesos authenticators, both HTTP and Crammd5 can be loaded as modules if you 
need a custom one. Documentation for modules is in the docs folder [1]. If you 
want to use HTTP authenticator, you need to implement the interface 
`process::http::authentication::Authenticator` [2], the same file where the 
interface is declared includes an example of an authenticator, you can check in 
the code for the definition. Once you have your own interface implementation 
ready, you can check the examples directory [3] as a guideline on how to make 
your authenticator available to mesos (that file combined with the modules 
documentation).

I hope that had been of help.


[1] http://mesos.apache.org/documentation/latest/modules/ 
<http://mesos.apache.org/documentation/latest/modules/>
[2] 
https://github.com/apache/mesos/blob/master/3rdparty/libprocess/include/process/authenticator.hpp
 
<https://github.com/apache/mesos/blob/master/3rdparty/libprocess/include/process/authenticator.hpp>
[3] 
https://github.com/apache/mesos/blob/master/src/examples/test_http_authenticator_module.cpp
 
<https://github.com/apache/mesos/blob/master/src/examples/test_http_authenticator_module.cpp>

Alexander Rojas
alexan...@mesosphere.io




> On 20 Mar 2017, at 18:11, Joao Costa <labremoted...@gmail.com> wrote:
> 
> Hello,
> 
> I'm trying to create a custom authentication and I was wondering if anyone
> could give me some help.
> 
> Is there any kind of documentation regarding the authentication process?
> 
> What about examples and/or "templates"? (i.e. getting the credentials from
> a database?
> 
> Any kind of help is more than welcome.
> 
> 
> Thanks

Re: Proposal for Mesos Build Improvements

[Alexander Rojas]

Actually, this is a policy I have never been a big fan of. In my experience 
just forward declaring as much as possible in the headers and only including in 
compilations units tend to have decent improvements in complication time, 
particularly files like `mesos.cpp` or `slave.cpp` which indirectly end up 
including almost every header in the project.

Alexander Rojas
alexan...@mesosphere.io




> On 15 Feb 2017, at 20:12, Neil Conway <neil.con...@gmail.com> wrote:
> 
> On Tue, Feb 14, 2017 at 11:28 AM, Jeff Coffler
> <jeff.coff...@microsoft.com.invalid> wrote:
>> For efficiency purposes, if a header file is included by 50% or more of the 
>> source files, it should be included in the precompiled header. If a header 
>> is included in fewer than 50% of the source files, then it can be separately 
>> included (and thus would not benefit from precompiled headers). Note that 
>> this is a guideline; even if a header is used by less than 50% of source 
>> files, if it's very large, we still may decide to throw it in the 
>> precompiled header.
> 
> It seems like this would have the effect of creating many false
> dependencies: if file X doesn't currently include header Y but Y is
> included in the precompiled header, the symbols in Y will now be
> visible when X is compiled. It would also mean that X would need to be
> recompiled when Y changes.
> 
> Related: the current policy is that headers and implementation files
> should try to include all of their dependencies, without relying on
> transitive includes. For example, if foo.cpp includes bar.hpp, which
> includes , but foo.cpp also uses , both foo.cpp and
> bar.hpp should "#include ". Adopting precompiled headers would
> mean making an exception to this policy, right?
> 
> I wonder if we should instead use headers like:
> 
> <- mesos_common.h ->
> #include 
> #include 
> #include 
> 
> <- xyz.cpp, which needs headers "b" and "d" ->
> #include "mesos_common.h>
> 
> #include 
> #include 
> 
> That way, the fact that "xyz.cpp" logically depends on  (but not
>  or ) is not obscured (in other words, Mesos should continue to
> compile if 'mesos_common.h' is replaced with an empty file). Does
> anyone know whether the header guard in  _should_ make the repeated
> inclusion of  relatively cheap?
> 
> Neil

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

[Alexander Rojas]

+1 (non-biding)

Ubuntu 16.04

../configure --enable-ssl --enable-libevent && sudo make check

On Mon, Oct 24, 2016 at 3:41 PM, Gastón Kleiman 
wrote:

> +1 (non-binding), "make check' and also Marathon's integration tests pass
> on OS X.
>
> -Gastón
>
> On Tue, Oct 18, 2016 at 10:01 PM, Till Toenshoff  wrote:
>
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos 1.1.0.
> >
> >
> > 1.1.0 includes the following:
> > 
> > 
> >   * [MESOS-2449] - **Experimental** support for launching a group of
> tasks
> > via a new `LAUNCH_GROUP` Offer operation. Mesos will guarantee that
> > either
> > all tasks or none of the tasks in the group are delivered to the
> > executor.
> > Executors receive the task group via a new `LAUNCH_GROUP` event.
> >
> >   * [MESOS-2533] - **Experimental** support for HTTP and HTTPS health
> > checks.
> > Executors may now use 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 

Re: Separate Compilation of Tests

[Alexander Rojas]

The workaround I use is to go to the folder of the makefile root directory, so 
for
Mesos, and then use the specific target, for example:

For mesos-tests
cd ${MESOS_SRC_ROOT}/build/src
make -j4 mesos-tests && ./mesos-tests

for libprocess
cd ${MESOS_SRC_ROOT}/build/3rdparty/libprocess
make -j4 libprocess-tests && ./libprocess-tests

for stout
cd ${MESOS_SRC_ROOT}/build/3rdparty/stout
make -j4 stout-tests && ./stout-tests

I don’t think it would be hard to add top level targets that just do that from 
the top level.

I however would like to have a target that compiles but not runs the tests.

> On 25 Sep 2016, at 15:56, Michael Park  wrote:
> 
> Hello,
> 
> I would like to propose a change in our build to help us improve developer
> efficiency.
> The proposal is to support separate compilation of unit tests.
> 
> Currently, we have the old approach of invoking `make check -j N
> GTEST_FILTER=""`, or a newer option of doing `make tests -j N`. From what
> I've heard the latter is slightly faster. However, when someone is
> developing a specific feature, it's likely that they would like to make
> changes and iterate on a single test file. In this workflow, having to
> compile (virtually) __all__ of the tests is very burdensome. This situation
> is not so bad if you're working in a very isolated part of the codebase,
> but it gets to be pretty bad if you're experimenting with parts that are
> widely used.
> 
> An example of a workflow I'm aiming for would look something like:
> 
>   1. write some code...
>   2. `make check master_tests`  // compile and test
>   `src/tests/master_tests.cpp`
>   3. fix compilation errors...
>   4. `make check master_tests`  // compile and test
>   `src/tests/master_tests.cpp`
>   5. change some stuff...
>   6. `make check master_tests`  // compile and test
>   `src/tests/master_tests.cpp`
>   7. debug...
>   8. `make check master_tests`  // compile and test
>   `src/tests/master_tests.cpp`
>   9. alright, looks good. `make check`
> 
> I have 0 attachment to the `make check master_tests` syntax. It'll be a
> different syntax for CMake anyways. I just think that the ability to
> perform separate compilation of tests will be immensely useful.
> 
> Some numbers to justify what I'm proposing:
> 
>   - `make -j 8` on my laptop takes roughly 10 mins.
>   - `make tests -j 8` takes about 30 mins.
> 
> Of course, not every change you make triggers all of the tests to
> recompile. But if you change components that are widely used, it does end
> up recompiling virtually everything. Under these circumstances, I would
> love for each iteration to be 11 mins (10 mins + __at most__ 1 min to
> compile the single test), rather than 30 mins.
> 
> NOTE: My laptop is expensive... some people even use machines with 64 cores
> or whatever to compile Mesos. Not everyone has access to this kind of
> equipment. We should strive for something better than "throw more money at
> it".
> 
> The goal of this thread for me is the following:
>  (1) Capture whether this is something most people experience, or whether
> I'm just doing it wrong
>  (2) If most people do experience this inefficiency and would like this
> change to be made,
>   I would like to recruit 1 or 2 people to help me deliver this, since
> I'm not a automake nor CMake expert.

Re: Lambdas: caveats, do's and don'ts

[Alexander Rojas]

Now that you touch the topic, I think that we need to expand our style guide 
concerning lambdas. The rules do not cover all the cases, e.g.

```
auto lambda = [a, long, number, of, captures](a, long, number, of, parameters) 
-> ExplicitReturnType {
}
```

so far, the formatting has been done based on what the shepherd thinks the
formatting should be, but is not always the same which causes sometimes
calling out other just to ask what the right formatting in a given context and
with a particular shepherd should be.


> On 06 Jul 2016, at 15:35, Alex Rukletsov  wrote:
> 
> Folks,
> 
> We've recently seen several bugs and potential issues related to lambda
> captures in our codebase. To help us avoid these problems in the future, we
> would like to touch on few general guidelines now. After 1.0 release, we
> will take some time and revisit our lambda guidelines and think about what
> primitives we can add in order to enforce the rules.
> 
> 1) Use `defer` to execute on the same context.
> If your lambda captures `this` to capture the actor context, most probably
> you want it to be executed in the actor’s context. you should use `defer()`
> to achieve this. For an example, see [1].
> 
> 2) `this` should typically point to the actor instance.
> When you capture `this`, make sure it represents the actor instance onto
> which you `defer()` or `dispatch()`. If you are doing otherwise, make sure
> you capture the reason in a comment. For an example, see [2], the second
> and the third hunks.
> 
> 3) Avoid capturing by reference.
> While capturing by reference is allowed, captured objects must not be
> destructed before they are used in the lambda. For an example, see [3].
> Except common cases, like using a library that always executes lambdas
> immediately [4], you should always write a comment explaining that capture
> by reference is done on purpose, e.g. [5]. IMPORTANT: capturing `this` by
> value and using a member variable is effectively capture by reference!
> 
> AlexR & MPark.
> 
> [1]
> https://github.com/apache/mesos/commit/97124ac72bbc42f809b800fe2da383dc43b1b34e
> [2]
> https://github.com/apache/mesos/commit/89d072d8567ccdcf11d1b1093350f393885fc593
> [3]
> https://github.com/apache/mesos/commit/54b82e5713243f44e7e2a617f53bce872381b36a
> [4]
> https://github.com/apache/mesos/blob/149f4c55b951e5eaea1cb5faf400089dd36c355a/src/master/http.cpp#L1251
> [5]
> https://github.com/apache/mesos/blob/149f4c55b951e5eaea1cb5faf400089dd36c355a/src/master/http.cpp#L1239-L1241

Re: [Tech-debt] Introduce regex into Mesos

[Alexander Rojas]

That was discussed in the past. The main issue is Mesos only bundles header 
only libraries and regex is a binary one.

> On 05 Jul 2016, at 19:53, haosdent  wrote:
> 
>> As Joseph said, regex works well in llvm 7.3 & gcc 5.3, but does not work
> in gcc 4.8.4; also try "" in gc 4.8.4, but "ld" failed :(.
> 
> I think we just need to update the bundled boost and use the regex headers
> from boost as what I do in
> https://reviews.apache.org/r/40053/diff/3#index_header
> 
> On Mon, Jun 13, 2016 at 9:58 PM, Klaus Ma  wrote:
> 
>> As discussed in the RR, we'll enhance current code to handle port ranges
>> as a short term solution.
>> 
>> 
>> I've logged MESOS-5602 (Introduce expression grammar library)<
>> https://issues.apache.org/jira/browse/MESOS-5602> to trace the long term
>> solution for Mesos defined data format, e.g. resources.
>> 
>> 
>> 
>> 
>> Da (Klaus), Ma (??), PMP®| Advisory Software Engineer
>> Platform DCOS Development & Support, STG, IBM GCG
>> +86-10-8245 4084 | mad...@cn.ibm.com | http://k82.me
>> 
>> 
>> 
>> 
>> 
>> From: Klaus Ma 
>> Sent: Saturday, June 11, 2016 2:09 AM
>> To: dev
>> Subject: Re: [Tech-debt] Introduce regex into Mesos
>> 
>> As Joseph said, regex works well in llvm 7.3 & gcc 5.3, but does not work
>> in gcc 4.8.4; also try "" in gc 4.8.4, but "ld" failed :(.
>> 
>> 
>> 
>> 
>> Da (Klaus), Ma (??), PMP(r)| Advisory Software Engineer
>> Platform DCOS Development & Support, STG, IBM GCG
>> +86-10-8245 4084 | mad...@cn.ibm.com | http://k82.me
>> 
>> 
>> 
>> From: Joseph Wu 
>> Sent: Friday, June 10, 2016 8:15:51 PM
>> To: dev
>> Subject: Re: [Tech-debt] Introduce regex into Mesos
>> 
>> Same here.
>> 
>> Mesos currently requires GCC 4.8.1+.  Regex support was implemented in GCC
>> 4.9.0, see [1].
>> 
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
>> 
>> On Fri, Jun 10, 2016 at 11:39 AM, Kevin Klues  wrote:
>> 
>>> By compiler errors, I mean "internal compiler errors"
>>> 
>>> On Fri, Jun 10, 2016 at 11:38 AM, Kevin Klues  wrote:
 I've run into compiler errors using simple regex stuff from the
 standard library on our supported version of gcc.
 
 On Thu, Jun 9, 2016 at 7:30 PM, Klaus Ma 
>> wrote:
> Hi team,
> 
> 
> We're discussing to introduce regex into Mesos when investigating
>>> MESOS-4627; so I'd
>> like
>>> to ask whether anyone has experience on regex after C++11? for example,
>>> supported compiler, compatibility, performance and so on :).
> 
> 
> 
> 
> Da (Klaus), Ma (??), PMP(r)| Advisory Software Engineer
> Platform DCOS Development & Support, STG, IBM GCG
> +86-10-8245 4084 | mad...@cn.ibm.com | http://k82.me
> 
> 
 
 
 
 --
 ~Kevin
>>> 
>>> 
>>> 
>>> --
>>> ~Kevin
>>> 
>> 
> 
> 
> 
> -- 
> Best Regards,
> Haosdent Huang

Re: WebUI authentication in 1.0.0-rc1

[Alexander Rojas]

I think we should also think more thoroughly about the expected behaviour
when we introduce new authorizable actions (and we most certainly will).
Since things may break particularly if users set the `permissive` ACL field
to false.

Perhaps initially, if no ACL is given for the new action we print a warning
message and behave as if the field had an ACL such as

```
{
  "principals": {"type": "ANY"}
  "action":{"type": "ANY"}
}
```

which effectively set a permissive rule for that action. The advantage is
that
it will give time for users to update the ACLs, the disadvantage is that we
would be introducing incorrect semantics (if temporarily).

The other idea would be to detect `permissive=false` and no ACLs given
for the new action and print a warning message about possible breaks
because of a change in the system, but no change in behaviour.

Any other ideas?

On Wed, Jun 8, 2016 at 1:30 AM, Greg Mann  wrote:

> Hi Evers,
> Thanks for testing this out! We should have called out this change more
> explicitly in the changelog; I've posted a patch here
>  to do that.
>
> Adding documentation with guidance on how to set ACLs to accomplish
> particular tasks (i.e., full use of the web UI) would be beneficial as
> well, but seems out of scope for the release notes. I've created a JIRA to
> update the authorization documentation here
> .
>
> Cheers,
> Greg
>
>
> On Mon, Jun 6, 2016 at 2:28 AM, Evers Benno  wrote:
>
> > Hi,
> >
> > thanks for the pointer. For people having the same problem, it seems
> > that you have to actually provide six new ACL rules to restore the
> > previous behaviour:
> >
> > get_endpoints, view_frameworks, view_tasks, view_executors,
> > access_sandboxes, and access_mesos_logs.
> >
> > On 03.06.2016 21:59, Michael Park wrote:
> > > Hello, I'm not exactly sure about whether the behavior is undesired or
> > not.
> > >
> > > But I think the ACL that you're missing is `GetEndpoint`:
> > >
> >
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> > >
> > > Hope that helps,
> > >
> > > MPark
> > >
> > > On 3 June 2016 at 12:36, Evers Benno  wrote:
> > >
> > >>
> > >> I just tried building and running the 1.0.0-rc1, and it seems that the
> > >> web UI is broken due to /metrics/snapshot returning a 403. (There's a
> > >> popup continously displaying "Failed to connect to
> > >> mesos-master.example.org:5050!"
> > >>
> > >> I'm running mesos-master with options `--no-authenticate_http
> > >> --acls={"permissive": "false", [...]}`, so I'm not completely sure if
> > >> this behaviour is as desired or not. (although its certainly
> unexpected)
> > >>
> > >> Regardless, I looked around for a while, but I couldn't figure out
> what
> > >> to add to the ACL to restore unauthorized viewing access for everyone?
> > >>
> > >> Best regards,
> > >> Benno
> > >>
> > >
> >
>

Re: mesos git commit: Added documentation for access_sandboxes and access_mesos_logs acls.

[Alexander Rojas]

Sorry guys, that was an oversight. I added reviews:

https://reviews.apache.org/r/48310/ <https://reviews.apache.org/r/48310/> - 
Fixes some endpoint spaces in docs.
https://reviews.apache.org/r/48311/ <https://reviews.apache.org/r/48311/> - 
Result of running the script.

> On 06 Jun 2016, at 23:54, Adam Bordelon <a...@mesosphere.io> wrote:
> 
> Good point. Vinod was working on the endpoints script right next to me, but
> I guess he did his pre-release run before I committed Alexander's change.
> We'll have to do another run before rc2.
> 
> On Mon, Jun 6, 2016 at 5:36 AM, Neil Conway <neil.con...@gmail.com> wrote:
> 
>> FYI, this commit should have included the changes produced by
>> re-running the `generate-endpoint.py` script.
>> 
>> Neil
>> 
>> On Wed, Jun 1, 2016 at 8:26 AM,  <m...@apache.org> wrote:
>>> Repository: mesos
>>> Updated Branches:
>>>  refs/heads/master 5263a6211 -> 53b5164bb
>>> 
>>> 
>>> Added documentation for access_sandboxes and access_mesos_logs acls.
>>> 
>>> Modifies the file `acls.proto` to take into consideration the added
>>> authorization actions `access_sandboxes` and `access_mesos_logs`.
>>> 
>>> Review: https://reviews.apache.org/r/48048/
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/53b5164b
>>> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/53b5164b
>>> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/53b5164b
>>> 
>>> Branch: refs/heads/master
>>> Commit: 53b5164bb51ebe850dec5ab19b8382f5c4a59391
>>> Parents: 5263a62
>>> Author: Alexander Rojas <alexan...@mesosphere.io>
>>> Authored: Tue May 31 23:20:50 2016 -0700
>>> Committer: Adam B <a...@mesosphere.io>
>>> Committed: Tue May 31 23:24:55 2016 -0700
>>> 
>>> --
>>> docs/authorization.md |  2 ++
>>> src/files/files.cpp   | 34 +++---
>>> 2 files changed, 33 insertions(+), 3 deletions(-)
>>> --
>>> 
>>> 
>>> 
>> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/docs/authorization.md
>>> --
>>> diff --git a/docs/authorization.md b/docs/authorization.md
>>> index 0e58b9b..189b70d 100644
>>> --- a/docs/authorization.md
>>> +++ b/docs/authorization.md
>>> @@ -131,6 +131,8 @@ entries, each representing an authorizable action:
>>> |`view_framework`|UNIX user of whom executors can be
>> viewed.|`Framework_Info` which can be viewed.|Filtering http endpoints.|
>>> |`view_executor`|UNIX user of whom executors can be
>> viewed.|`Executor_Info` and `Framework_Info` which can be viewed.|Filtering
>> http endpoints.|
>>> |`view_task`|UNIX user of whom tasks can be viewed.|(`Task` or
>> `Task_Info`) and `Framework_Info` which can be viewed.|Filtering http
>> endpoints.|
>>> +|`access_sandboxes`|Operator username.|Operating system user whose
>> executor/task sandboxes can be accessed.|Access task sandboxes.|
>>> +|`access_mesos_logs`|Operator username.|Implicitly given. A user should
>> only use types ANY and NONE to allow/deny access to the log.|Access Mesos
>> logs.|
>>> 
>>> ### Examples
>>> 
>>> 
>>> 
>> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/src/files/files.cpp
>>> --
>>> diff --git a/src/files/files.cpp b/src/files/files.cpp
>>> index 873664d..094a00c 100644
>>> --- a/src/files/files.cpp
>>> +++ b/src/files/files.cpp
>>> @@ -57,6 +57,7 @@
>>> using namespace process;
>>> 
>>> using process::AUTHENTICATION;
>>> +using process::AUTHORIZATION;
>>> using process::DESCRIPTION;
>>> using process::HELP;
>>> using process::TLDR;
>>> @@ -295,7 +296,16 @@ const string FilesProcess::BROWSE_HELP = HELP(
>>> "Query parameters:",
>>> "",
>>> ">path=VALUE  The path of directory to
>> browse."),
>>> -AUTHENTICATION(true));
>>> +AUTHENTICATION(true),
>>> +AUTHORIZATION(
>>> +"Browsing files requires that the request principal 

Re: Line length in docs

[Alexander Rojas]

+1 (Actually more like +10)

But I think your reasons are not the main problem in solving this issue. For 
me, when we have whole paragraphs in one line, and I want to see the changes in 
the document, even adding a comma renders the whole paragraph as changed, which 
makes the tracking of changes extremely painful.

> On 05 May 2016, at 15:29, Alex Rukletsov  wrote:
> 
> What do folks think about introducing a limit for line length in docs?
> First off, here are my thoughts against the limit:
>  * We should be careful about introducing more hurdles, especially for
> docs. We want people, also contributors outside the community, to improve
> documentation; hence we should make the process easier, or at least not
> more complicated.
>  * People usually render docs locally in a markdown application, that's
> why line length is not that crucial like comments length.
> 
> However, I often find myself reading and updating docs from the same editor
> I read and write code. In this case, 700+ lines become annoying, see e.g.
> [1].
> 
> My proposal is:
>  * have an agreement among committers, i.e. put it into "committing.md",
> that lines in docs are generally limited to 80 chars;
>  * refrain from putting this limit in both "markdown-style-guide.md" and
> "c++-style-guide.md";
>  * sweep-update all existing docs so contributors can follow the pattern.
> 
> [1]
> https://github.com/apache/mesos/blob/a138e2246a30c4b5c9bc3f7069ad12204dcaffbc/docs/architecture.md

Re: Should "read-only" HTTP endpoints allow other request methods than "GET"?

[Alexander Rojas]

I like the idea of using HTTP GET only, or at least a way to verify the 
method as early as possible.

When discussing authorization, something that occur to me is that authorization 
is a potentially expensive call, so if we can discard the request as early as 
possible because the method doesn’t match, it reduces the need to process
and unnecessary request.

> On 10 May 2016, at 15:37, Jan Schlicht  wrote:
> 
> Hi guys,
> 
> while working on HTTP endpoint authorization for Mesos, I found some
> interesting behavior: It's the responsibility of the HTTP endpoint handlers
> to validate the HTTP request method they've been called with. Many
> "read-only" endpoints (e.g. "/flags", "/state") don't do this at the
> moment. This means that it's possible to send, for example, an HTTP "POST"
> to the "/state" endpoint and get the same results as if it would have been
> an HTTP "GET".
> While this is currently not a problem, it will complicate things when we
> want to authorize endpoint access. The authorization should take the HTTP
> request method into account to distinguish between "user wants read access
> to the endpoint" and "user wants write access to the endpoint". This makes
> it ambitious on how to handle these "read-only" endpoints that also accept
> a "POST" request.
> The solution to that problem would be to add HTTP request method validation
> to every endpoint, i.e. the read-only endpoints would reject any request
> method that isn't "GET". I've created MESOS-5346 for that.
> Because that would change the existing behavior, that allows to e.g. "POST"
> to a "read-only" endpoint, I'd like to know if anybody relies on that
> behavior, or if there are any other objections on changing it.
> 
> Cheers,
> Jan

[Proposal] Authorization support for task sandboxes

[Alexander Rojas]

As part of our work towards better security in Mesos, we have been working
on a proposal to protect the sandboxes of the launched tasks. Here [1] we 
propose a mechanism used to achieve such goal.

We welcome any comments and suggestions on it.

Looking forward to your feedback.

[1] 
https://docs.google.com/document/d/1OO0gUvzHt860fnne3Y8u6p2YyfJw-DTCd5imMlCBnjM 

 

Re: Design Doc for Qemu/KVM containerizer

[Alexander Rojas]

Hi Haosdent,

Till had an accident and will be out for a while, your reviews may take a while 
or otherwise you may consider getting help from a second shepherd.

> On 07 Apr 2016, at 17:00, haosdent  wrote:
> 
> Hi, @Abhishek Thanks your nice design document. I just take a look your
> code in
> https://github.com/abdasgupta/mesos/commit/e845ee70602dfc774381996f884587578c07a25b
> . It looks like a prototype now. Do you every consider implement it through
> the module way. Refer to the ticket [Modularize the containerizer
> interface](https://issues.apache.org/jira/browse/MESOS-3709) and the
> document [Containerizer Modularization Design](
> https://docs.google.com/document/d/1fj3G2-YFprqauQUd7fbHsD03vGAGg_k_EtH-s6fRkDo/edit?usp=sharing
> ).
> 
> As you know, you have the ticket about add support to rkt container(
> https://issues.apache.org/jira/browse/MESOS-2162) and hyper container(
> https://issues.apache.org/jira/browse/MESOS-3435). We may like to support
> more container types in the future. I think add the support to these
> container types through module way would be better.
> 
> Current my work status about [Modularize the containerizer interface](
> https://issues.apache.org/jira/browse/MESOS-3709) is public all my patches
> a week ago and not yet been reviewed. And I could not contact with till to
> review my design doc in past month. So the design may change in the future.
> Looking forward your feedbacks and concerns about this. I would appreciated
> for that.
> 
> On Thu, Apr 7, 2016 at 8:34 PM, Abhishek Dasgupta <
> a10gu...@linux.vnet.ibm.com> wrote:
> 
>> Hi all,
>> 
>> I uploaded a design doc for Mesos-2717:
>> 
>> 
>> https://docs.google.com/document/d/1_VuFiJqxjlH_CA1BCMknl3sadlTZ69FuDe7qasDIOk0/edit?usp=sharing
>> 
>> Need your views and comments on it.
>> 
>> --
>>  Regards,
>> 
>> 
>> ---
>>  Abhishek Dasgupta
>>  Linux Software Developer - Linux Technology Centre
>>  IBM Systems Lab,
>>  IBM India Pvt. Ltd.
>>  Embassy Golf Link, D Block
>>  Koramongala - Off Indiranagar Ring Road
>>  Bangalore - 560 071
>>  Mobile: +91-8884107981
>> 
>> ---
>> 
>> 
> 
> 
> -- 
> Best Regards,
> Haosdent Huang

Re: Typed Error Handling in Mesos

[Alexander Rojas]

+1 

What I like is that it allows from some kind of type safety into the error 
management beyond trying to parse error strings.

> On 05 Apr 2016, at 03:48, Michael Park  wrote:
> 
> Contrary to standard C++ practices, Mesos uses return values as the
> mechanism
> for error handling rather than exceptions.
> 
> This proposal is simply an evolution of the current mechanism we have in
> Mesos today.
> This direction is consistent with the designs made in Rust, which uses
> return values as
> the error handling mechanism at the language level.
> 
> The first step is to add an additional template parameter to class template
> *Try*, to get *Try*.
> 
> The proposed design defaults* E *to *Error*, and requires that *E* be, or
> is inherited from *Error*.
> The return type of *error()* is *const std::string&* if *E == Error* and
> *const E&* otherwise,
> for backwards-compatibility reasons.
> 
> So in the end, *Try* behaves exactly as before.
> 
> The work is being tracked in MESOS-5107
> , and i've written a
> quick design doc
> 
> capturing
> some of the preliminary thoughts on this topic, and a proposal for an
> immediate use case
> for the Windows work.
> 
> If you're interested in how Rust deals with error handling, check out
> https://doc.rust-lang.org/book/error-handling.html. Our *Option* is their
> *Option*,
> our *Try* is their *Result*, and they don't have our *Result*.
> 
> I'm going to be pushing the changes proposed shortly, but the changes are
> small and
> does not require a large sweeping changes or anything like that.
> So please reach out to me with your concerns and complaints and I will be
> sure to address them.
> 
> Thanks,
> 
> MPark

Re: Compile failure

[Alexander Rojas]

Hi Walter, 

I once had the same problem. The solution is to move to subversion 1.8, so as 
super user try:

# Change version in the repository
sed -i "s/1.9/1.8/g" /etc/yum.repos.d/wandisco-svn.repo

# Remove cache files
rm -rf /var/cache/yum/x86_64/7Server/WANdiscoSVN/*

# Rebuild the cache
yum makecache

# Retry installation
yum group install -y "Development Tools”

One more thing, don’t know if this has any real effect, but my 
/etc/yum.repos.d/wandisco-svn.repo looks as follows:

[WANdiscoSVN]
name=WANdisco SVN Repo 1.9
enabled=1
baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/$basearch/
gpgcheck=1
gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco


> On 10 Mar 2016, at 10:38, Walter Heestermans (TME) 
>  wrote:
> 
> I removed the subversion packages
>  
> yum remove  -y subversion-libs subversion subversion-devel
>  
> Update the repo info for subversion 1.9:
>  
> cat /etc/yum.repos.d/wandisco-svn.repo
> [WANdiscoSVN]
> name=WANdisco SVN Repo 1.9
> enabled=1
> baseurl=http://opensource.wandisco.com/centos/7/svn-1.9/RPMS/x86_64/ 
> 
> gpgcheck=1
> gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco 
> 
>  
> Try to reinstall
>  
> yum install  -y subversion-libs subversion subversion-devel
> Loaded plugins: ulninfo
> Resolving Dependencies
> --> Running transaction check
> ---> Package subversion.x86_64 0:1.9.3-1 will be installed
> --> Processing Dependency: libserf-1.so.0()(64bit) for package: 
> subversion-1.9.3-1.x86_64
> ---> Package subversion-devel.x86_64 0:1.9.3-1 will be installed
> --> Processing Dependency: pkgconfig(serf-1) for package: 
> subversion-devel-1.9.3-1.x86_64
> --> Processing Dependency: pkgconfig(sqlite3) for package: 
> subversion-devel-1.9.3-1.x86_64
> --> Processing Dependency: pkgconfig(gnome-keyring-1) for package: 
> subversion-devel-1.9.3-1.x86_64
> ---> Package subversion-libs.x86_64 0:1.7.14-10.el7 will be installed
> --> Running transaction check
> ---> Package libgnome-keyring-devel.x86_64 0:3.8.0-3.el7 will be installed
> --> Processing Dependency: libgnome-keyring = 3.8.0-3.el7 for package: 
> libgnome-keyring-devel-3.8.0-3.el7.x86_64
> --> Processing Dependency: pkgconfig(glib-2.0) for package: 
> libgnome-keyring-devel-3.8.0-3.el7.x86_64
> --> Processing Dependency: glib2-devel for package: 
> libgnome-keyring-devel-3.8.0-3.el7.x86_64
> --> Processing Dependency: libgnome-keyring.so.0()(64bit) for package: 
> libgnome-keyring-devel-3.8.0-3.el7.x86_64
> ---> Package serf-devel.x86_64 0:1.3.7-1 will be installed
> ---> Package sqlite-devel.x86_64 0:3.7.17-8.el7 will be installed
> ---> Package subversion.x86_64 0:1.9.3-1 will be installed
> --> Processing Dependency: libserf-1.so.0()(64bit) for package: 
> subversion-1.9.3-1.x86_64
> --> Running transaction check
> ---> Package glib2-devel.x86_64 0:2.42.2-5.el7 will be installed
> ---> Package libgnome-keyring.x86_64 0:3.8.0-3.el7 will be installed
> ---> Package subversion.x86_64 0:1.9.3-1 will be installed
> --> Processing Dependency: libserf-1.so.0()(64bit) for package: 
> subversion-1.9.3-1.x86_64
> --> Finished Dependency Resolution
> Error: Package: subversion-1.9.3-1.x86_64 (WANdiscoSVN)
>Requires: libserf-1.so.0()(64bit)
> You could try using --skip-broken to work around the problem
> You could try running: rpm -Va --nofiles –nodigest
>  
> Found this link about the missing library
>  
> https://issues.apache.org/jira/browse/MESOS-3842 
> 
>  
> 
>  
> I tried to follow the following procedure
>  
> http://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/ 
> 
>  
> rpm -ivh /tmp/epel-release-7-5.noarch.rpm
> warning: /tmp/epel-release-7-5.noarch.rpm: Header V3 RSA/SHA256 Signature, 
> key ID 352c64e5: NOKEY
> Preparing...  # [100%]
> Updating / installing...
>1:epel-release-7-5 # [100%]
>  
> Restarted the installation
>  
> yum install  -y subversion-libs subversion subversion-devel
>  
> Loaded plugins: ulninfo
> epel/x86_64/metalink  
>   
>   |  25 kB  00:00:00  
>
> epel  
>   
>   | 4.3 kB  00:00:00  
>
> (1/3): epel/x86_64/group_gz   
>   

Re: Executors no longer inherit environment variables from the agent

[Alexander Rojas]

Not that I know a lot about this project, but I think for the command executor 
we can use the `Environment` message. Perhaps we can extend the container info 
to have something similar?


> On 10 Mar 2016, at 12:50, Alex Rukletsov  wrote:
> 
> I have two questions.
> 
> First, does this change include the executor library? We currently use 
> environment variables to propagate various config values from an agent to 
> executors. If it does, what is the alternative?
> 
> Second, what will be the preferred way to pass config values to executors? It 
> would be great to be able to do it uniformly for non-HTTP and HTTP executors. 
> I can think of several possibilities: cmd flags, adding or overriding 
> protobufs, extending Executor interface.
> 
> On Tue, Mar 8, 2016 at 9:21 PM, Gilbert Song  > wrote:
> Yes, `LIBPROCESS_IP` will be excepted from this change. We will still have 
> `LIBPROCESS_IP` set and passed to executors' environment, which is for the 
> case that DNS is not available on the slave.
> 
> Gilbert
> 
> On Tue, Mar 8, 2016 at 11:57 AM, Zhitao Li  > wrote:
> Is LIBPROCESS_IP going to be an exception to this? Some executors are using 
> this variable as an alternative of implementing their own IP detection logic 
> AFAIK so this behavior would break them.
> 
> On Tue, Mar 8, 2016 at 11:33 AM, Gilbert Song  > wrote:
> Hi,
> 
> TL;DR Executors will no longer inherit environment variables from the agent 
> by default in 0.30.
> 
> Currently, executors are inheriting environment variables form the agent in 
> mesos containerizer by default. This is an unfortunate legacy behavior and is 
> insecure. If you do have environment variables that you want to pass to the 
> executors, you can set it explicitly by using the 
> `--executor_environment_variables` agent flag.
> 
> Starting from 0.30, we will no longer allow executors to inherit environment 
> variables from the agent. In other words, `--executor_environment_variables` 
> will be set to “{}” by default. If you do depend on the original behavior, 
> please set `--executor_environment_variables` flag explicitly.
> 
> Let us know if you have any comments or concerns.
> 
> Thanks,
> Gilbert
> 
> 
> 
> -- 
> Cheers,
> 
> Zhitao Li
> 
> 

Re: Negative durations

[Alexander Rojas]

IMO durations should not be negative. The problem with having them define an 
infinite period is the following:

Lets say you want to compute the duration between two durations A and B:
  C = A-B;
if A < B, C is negative and it will be infinite.

I one want’s to check for the case mentioned in [1] about sleeping 0 marked 
with a negative duration, I think adding an explicit `if` is better since it 
reflects the intention.

So in to conclude:

1. Duration operations should always be positive so A-B is effectively 
|A.underlying_type - B.underlying_type|.
2. We do need a constant or an specific trait to represent an infinite duration.

> On 09 Mar 2016, at 17:20, Klaus Ma  wrote:
> 
> One case I can image is to use negative value for forever duration?
> 
> 
> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> Platform OpenSource Technology, STG, IBM GCG
> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> 
> On Wed, Mar 9, 2016 at 8:21 PM, Alex Rukletsov  wrote:
> 
>> Folks,
>> 
>> I've recently realized that durations we use in mesos (stout's `Duration`
>> and `DurationInfo` protobuf) are based on signed integers. Negative
>> duration concept is a bit strange to me, so I googled around a bit and
>> found an interesting thread [1].
>> 
>> Was it an explicit intention to allow `Duration`s to be negative? Do we use
>> this feature? If yes, maybe we can introduce a class representing time
>> delta (can be negative) and base `Duration` on top of it guaranteeing it is
>> always non-negative?
>> 
>> My ultimate intention is to avoid boilerplate code that validates every
>> single instance of `Duration` in the codebase. I'd rather have a class with
>> guarantees certain invariants.
>> 
>> [1] https://internals.rust-lang.org/t/unsigned-version-of-duration/893/2
>> 

Re: Making 'curl' a prerequisite for installing Mesos

[Alexander Rojas]

I also have my doubts about this idea. Given that we support some legacy 
systems and the user interface tends to be less stable than an API (though 
comparing the flags between curl 7.38.0 in Debian 8 and curl 7.19.7 in CentOS 
6.7, I don’t see a lot of differences in the important ones).

So I guess what I am trying to say is, if we go this route, let’s make sure it 
is fully compatible across versions and the behavior is uniform.


> On 03 Mar 2016, at 18:39, Alex Clemmer  wrote:
> 
> Looks like the relevant review is this one:
> https://reviews.apache.org/r/40418/diff/3#4
> 
> I _suspect_ this will work with Windows, but am not positive.
> Optimistically, it's not clear to me whether it makes sense to add it
> as a dependency, because I don't know how to get its location reliably
> on Windows. Because Windows has no package manager, we actually rope
> it in the libcurl dependency from CMake, at build time. Seems like the
> thing to do might be to just build the exe as well and dispatch to
> that but this will require some modifications to this code.
> 
> On Thu, Mar 3, 2016 at 5:46 PM, Guangya Liu  wrote:
>> libcurl can automatically picks up certain environment variables and
>> adjusts its settings accordingly, so libcurl support enabling http_proxy
>> and https_proxy by default, this is important feature for someone who want
>> to use a proxy to connect internet. One example is that I cannot get google
>> docker images but need a proxy set in China.
>> 
>> If we depend on "curl" (I saw that we already finished the this in
>> MESOS-2840) when using fetcher, I think that we may also need to enable
>> slave to pass a proxy to fetch curl to enable someone can pull google
>> docker images under a firewall. Does it make sense file a JIRA to support
>> http proxy?
>> 
>> Thanks,
>> 
>> Guangya
>> 
>> On Fri, Mar 4, 2016 at 9:39 AM, Klaus Ma  wrote:
>> 
>>> +1 to add 'curl' dependency firstly.
>>> 
>>> 
>>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
>>> Platform OpenSource Technology, STG, IBM GCG
>>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
>>> 
>>> On Fri, Mar 4, 2016 at 5:04 AM, Jojy Varghese  wrote:
>>> 
 +1
 
 On Thu, Mar 3, 2016 at 12:52 PM Jake Farrell 
>>> wrote:
 
> +1
> 
> -Jake
> 
> On Thu, Mar 3, 2016 at 12:10 PM, Jie Yu  wrote:
> 
>> Hi,
>> 
>> I am proposing making 'curl' a prerequisite when installing Mesos.
>> Currently, we require 'libcurl' being present when installing Mesos (
>> http://mesos.apache.org/gettingstarted/). However, we found that it
 does
>> not compose well with our asynchronous runtime environment (i.e.,
>>> it'll
>> block the current worker thread).
>> 
>> Recent work on URI fetcher
>>  uses 'curl'
 directly,
>> instead of using 'libcurl' to fetch artifacts, because it composes
>>> well
>> with our async runtime env. 'curl' is installed by default in most
> systems
>> (e.g., OSX, centos, RHEL).
>> 
>> So I am proposing adding 'curl' to our prerequisite list. Let me know
 if
>> you have any concern on this. I'll update the Getting Started doc if
 you
>> are OK with this change.
>> 
>> Thanks,
>> - Jie
>> 
> 
 
>>> 
> 
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

[proposal] Generalized Authorizer Interface

[Alexander Rojas]

Hey guys,

After many discussions and back and forth, it was decided to revived the 
already deprecated design [1] for the internal authorizer interface.

Sorry for asking you again to review this document but any comment will be 
gladly welcome.

Best,

Alexander Rojas


[1] 
https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ

Re: On implicit construction of objects whose constructor takes multiple parameters

[Alexander Rojas]

That was my first thought, however most of our code doesn’t mark multiple
argument constructors as `explicit` as this hasn’t been traditionally necessary
so I was thinking on assuming they are until we somehow manage to mark
all existing constructors as `explicit`.

> On 01 Mar 2016, at 21:41, Michael Park <mp...@apache.org> wrote:
> 
> What I would propose is to update the style guide to say that a constructor
> be marked *explicit* if implicit conversion or list-initialization is
> undesired.
> That is, rather than only marking single-argument constructors as
> *explicit* which
> only covers implicit conversions, we should also mark multi-argument
> constructors as *explicit* if desired, to also cover list-initialization.
> 
> In this specific case, if you don't want to construct *Gauge* with {x, y,
> z}, rather than everyone having to remember at every call-site to say
> *Gauge*, they can be enforced that by marking *Gauge*'s constructor
> *explicit.*
> 
> On 1 March 2016 at 11:24, Michael Browning <invitapri...@gmail.com> wrote:
> 
>> I've seen braced initialization in a lot of contexts where the class of the
>> object being initialized doesn't define an initializer_list constructor, so
>> in that sense I think it's an idiomatic usage, and it has the advantage of
>> disallowing narrowing implicit conversions like double to int. On the other
>> hand, widespread use of braced initialization can cause some pain when you
>> inadvertently use it for a type that does take an initializer_list when you
>> meant to refer to a different constructor. I think the the latter case is
>> worth avoiding, and in my opinion your proposal is in line with the spirit
>> of the Mesos style guide as regards type deduction using auto, where it
>> states:
>> 
>> The main goal is to increase code readability. This is safely the case if
>> the exact same type omitted on the left is already fully stated on the
>> right.
>> 
>> 
>> In your example case with the braced initializer, the type isn't stated. I
>> agree that the explicit construction should be required.
>> 
>> On Mon, Feb 29, 2016 at 3:14 PM, Alexander Rojas <alexan...@mesosphere.io>
>> wrote:
>> 
>>> Hi Guys,
>>> 
>>> Today I was making a code review and I came across the following snippet:
>>> 
>>> ```
>>> metrics.allocated.put(
>>>name,
>>>{strings::join("/", "allocator/allocated", name),
>>> process::defer(self(), [this, name]() {
>>>   double result = 0;
>>>   foreachvalue (const Slave& slave, this->slaves) {
>>> Option value =
>>>   slave.allocated.get(name);
>>> if (value.isSome()) {
>>>   result += value.get().value();
>>> }
>>>   }
>>>   return result;
>>>})});
>>> ```
>>> 
>>> I think by the code here is hard to tell what is happening here. If you
>>> look at the declaration of `metrics.allocated` somewhere else you notice
>>> that allocated has the following declaration:
>>> 
>>> ```
>>> hashmap<std::string, process::metrics::Gauge> total;
>>> ```
>>> 
>>> And gauge is certainly no container type, nor its constructor takes an
>>> `std::initializer_list` as a parameter. In fact its signature is:
>>> 
>>> ```
>>> Gauge::Gauge(const std::string& name, const Deferred<Future()>&
>> f)
>>> ```
>>> 
>>> What is happening here is that brace constructors allows you to infer the
>>> type being constructed, which makes the snippet there be equivalent to:
>>> 
>>> ```
>>> metrics.allocated.put(
>>>name,
>>>Gauge(
>>>strings::join("/", "allocator/allocated", name),
>>>process::defer(self(), [this, name]() {
>>>  double result = 0;
>>>  foreachvalue (const Slave& slave, this->slaves) {
>>>Option value =
>>>  slave.allocated.get(name);
>>>if (value.isSome()) {
>>>  result += value.get().value();
>>>}
>>>  }
>>>  return result;
>>>   })));
>>> ```
>>> 
>>> What I’m proposing is to only allow this type of construction in a few
>>> cases, namely for tuples, pairs and initializer lists where it actually
>>> improves readability.
>>> 
>>> Do you guys have any opinions on the matter?
>> 

On implicit construction of objects whose constructor takes multiple parameters

[Alexander Rojas]

Hi Guys,

Today I was making a code review and I came across the following snippet:

```
metrics.allocated.put(
name,
{strings::join("/", "allocator/allocated", name),
 process::defer(self(), [this, name]() {
   double result = 0;
   foreachvalue (const Slave& slave, this->slaves) {
 Option value =
   slave.allocated.get(name);
 if (value.isSome()) {
   result += value.get().value();
 }
   }
   return result;
})});
```

I think by the code here is hard to tell what is happening here. If you look at 
the declaration of `metrics.allocated` somewhere else you notice that allocated 
has the following declaration:

```
hashmap total;
```

And gauge is certainly no container type, nor its constructor takes an 
`std::initializer_list` as a parameter. In fact its signature is:

```
Gauge::Gauge(const std::string& name, const Deferred& f)
```

What is happening here is that brace constructors allows you to infer the type 
being constructed, which makes the snippet there be equivalent to:

```
metrics.allocated.put(
name,
Gauge(
strings::join("/", "allocator/allocated", name),
process::defer(self(), [this, name]() {
  double result = 0;
  foreachvalue (const Slave& slave, this->slaves) {
Option value =
  slave.allocated.get(name);
if (value.isSome()) {
  result += value.get().value();
}
  }
  return result;
   })));
```

What I’m proposing is to only allow this type of construction in a few cases, 
namely for tuples, pairs and initializer lists where it actually improves 
readability.

Do you guys have any opinions on the matter?

Re: [proposal] Generalized Authorized Interface

[Alexander Rojas]

Hi Guys,

After addressing the issues you presented about the authorizer interface, we 
updated the design [1]. Please comment on it.

Best,

Alexander Rojas

[1] 
https://docs.google.com/document/d/1gCR6fpD_1wKbVUtj6iP2sqsARtMfgTz5YJpJ1nd7zBA/

> On 22 Feb 2016, at 10:48, Alexander Rojas <alexan...@mesosphere.io> wrote:
> 
> Hey guys,
> 
> After some extra thought, we came to what we think is a nice interface for 
> the Mesos authorizer [1] which will allow users of Mesos to use to your 
> custom backends in a nice way. Please share your thoughts with us in case we 
> missed something or there are improvements we can make to the interface.
> 
> [1] 
> https://docs.google.com/document/d/1gCR6fpD_1wKbVUtj6iP2sqsARtMfgTz5YJpJ1nd7zBA/

[proposal] Generalized Authorized Interface

[Alexander Rojas]

Hey guys,

After some extra thought, we came to what we think is a nice interface for the 
Mesos authorizer [1] which will allow users of Mesos to use to your custom 
backends in a nice way. Please share your thoughts with us in case we missed 
something or there are improvements we can make to the interface.

[1] 
https://docs.google.com/document/d/1gCR6fpD_1wKbVUtj6iP2sqsARtMfgTz5YJpJ1nd7zBA/

Re: Enable compiler optimization by default?

[Alexander Rojas]

+1

Since the old days users are used to run

```
configure
make
sudo make install
```

and things just work. With the model we have, we are just encouraging users to 
run their data centers with unoptimized versions of Mesos, which just hurts 
their performance.


> On 17 Feb 2016, at 16:24, Neil Conway  wrote:
> 
> Hi folks,
> 
> At present, Mesos defaults to compiling with "-O0"; to enable compiler
> optimizations, the user needs to specify "--enable-optimize".
> 
> I'd like to propose we change the default, for a few reasons:
> 
> (1) The autoconf default for CFLAGS/CXXFLAGS is "-O2 -g". Anecdotally,
> I think most software packages compile with a reasonable level of
> optimizations enabled by default.
> 
> (2) I think we should make the default configure flags appropriate for
> end-users (rather than Mesos developers): developers will be familiar
> enough with Mesos to tune the configure flags according to their own
> preferences.
> 
> (3) The performance consequences of not enabling compiler
> optimizations can be pretty severe: 5x in a benchmark I just ran, and
> we've seen between 2x and 30x (!) performance differences for some
> real-world workloads.
> 
> Neil

Re: Inconsistent naming of support scripts

[Alexander Rojas]

+1 for consistency, +1 for executables.

I do enough finger yoga while using emacs!

running `find /usr/local/bin -name "*-*" | wc -l` returned 142 while `find 
/usr/local/bin -name "*_*" | wc -l` was only 17. So I feel using hyphen for 
executables is more standard.

> On 11 Feb 2016, at 14:58, Michael Park  wrote:
> 
> +1 for consistency, +1 for hyphens for executables.
> 
> On 11 February 2016 at 14:25, Kevin Klues  wrote:
> 
>> I typically think of files having dashes as binaries or scripts that
>> are runnable, whereas files with underscores are meant as source or
>> otherwise supplementary to the binary produced (e.g. a supplementary
>> python library that the main python program imports).  I'm  not sure
>> where I inherited this convention from, but it's always been the way
>> I've done things.
>> 
>> As far as our code base goes, we seem to use this convention as well
>> with our mesos-master.sh. mesos-slave.sh, etc. binaries.
>> 
>> On Thu, Feb 11, 2016 at 2:17 PM, Vinod Kone  wrote:
>>> Why hyphens? Most of the files in our repo use underscores. I would like
>> us
>>> to be consistent on how we name files in the repo.
>>> 
>>> On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues  wrote:
>>> 
 I prefer hyphens as well
 
 On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese 
>> wrote:
> hyphen++. Is google friendly apparently.  Also less keys to press :)
> 
> -Jojy
> 
> 
> 
>> On Feb 11, 2016, at 12:43 PM, Greg Mann  wrote:
>> 
>> +1
>> 
>> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone 
 wrote:
>> 
>>> Some the scripts in the "support" directory have dashes ("-") in
>> their
>>> names (e.g., apply-review.sh, apply-reviews.py), whereas some have
>>> underscores ("_") (e.g., docker_build.sh, mesos_split.py).
>>> 
>>> This is really confusing and we should stick with one style. I
>> propose
 to
>>> change all them to use underscores. I will make sure the CI jobs are
>>> updated accordingly.
>>> 
>>> Any objections?
>>> 
>>> Thanks,
>>> Vinod
>>> 
> 
 
 
 
 --
 ~Kevin
 
>> 
>> 
>> 
>> --
>> ~Kevin
>> 

Re: Reorganize 3rdparty directory

[Alexander Rojas]

+1
I am one who is totally in for that change. It is not only the directories 
problem, but the structure which has led that the stout tests (which do need to 
be compiled) are actually managed in the libprocess Makefile, on top of all the 
things you have already mentioned.


> On 09 Feb 2016, at 17:53, Kapil Arya  wrote:
> 
> On Tue, Feb 9, 2016 at 8:23 PM, Jie Yu  wrote:
>> Kapil,
>> 
>> I guess what I want to understand is why the existing structure makes it
>> hard for you to do the things that you want to do (installing
>> module-specific 3rdparty dependencies into "${pkglibdir}/3rdparty" as part
>> of "make install").
> 
> Let me see if I can answer that :-).
> 
> This is somewhat related. For example, if we want to install protobuf
> in 3rdparty/{include,lib} (for module developers to use them without
> doing a proper mesos installation), you need to provide the correct
> "--prefix" flag that points to 3rdparty/. However, due to multiple
> levels of configure.ac, the "--prefix" can at best be generated by
> prepending "../../../" to get to the great-grandparent directory. This
> is because we have a separate configure.ac which manages
> 3rdparty/libprocess/3rdparty/Makefile.am. There are ways around it,
> but they are not clean.
> 
> Similar thing holds for system-wide installation of these 3rdparty
> packages. For example, ideally, we would want to use
> "${pkglibdir}/3rdparty" as a prefix for those packages. However, since
> they are part of libprocess package, we don't get the correct
> directory and have to use either hardwired $pkglibdir, or somehow pass
> it from the top-level configure all the way down to
> 3rdparty/libprocess/3rdparty/Makefile.am :-(.
> 
> 
>> The only reason you mentioned in the original email is that "in the current
>> code base, we don't strictly follow the 3rdparty structure", which IMO is
>> not a very convincing reason for such a big change.
> 
> How about a not so big change? :-). What if we just move
> 3rdparty/libprocess/3rdparty/* stuff out to 3rdparty/ while leaving
> stout as is? That is not a big change since we are not touching
> libprocess/stout. Just adjusting Makefiles and I am pretty sure it
> will be cleaner and simpler than what we have right now.
> 
> As a later time, we can then consider moving stout out to 3rdparty/
> while leaving libprocess as is. But that's something we can decide
> later and leave stout as an exception for now.
> 
> BTW, if we were to install all the 3rdparty packages in 3rdparty/,
> that would also cut down a lot on the compiler flags (i.e., fewer "-I"
> and "-L" flags) :-).
> 
> Kapil
> 
>> 
>> - Jie
>> 
>> On Tue, Feb 9, 2016 at 5:04 PM, Kapil Arya  wrote:
>> 
>>> On Tue, Feb 9, 2016 at 7:20 PM, Jie Yu  wrote:
 
> 
> However, in the current code base, we don't strictly follow the
>>> 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages inside
> 3rdparty/libprocess/3rdparty/stout/3rdparty/.
 
 
 My understanding is that stout is header only. So it does not have to
 bundle 3rdparty libraries. The user of stout is responsible for bundling
 them if they are used.
>>> 
>>> 
>>> I don't think being header-only is an excuse to have a broken
>>> installation :-). Further, we don't make it easier for the user to get
>>> the 3rdparty binaries either. For example, if the user has a different
>>> version of protobuf installed on the system, the compilation of any
>>> program that uses stout will fail spectacularly!
>>> 
>>> Having said that, the gist here is that we have somewhat deviated from
>>> original motivation behind the 3rdparty directory and it would be nice
>>> if we can have a flatter structure.
>>> 
 
 
 - Jie
 
 On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya  wrote:
 
> Hi All,
> 
> TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into
>>> 3rdparty/.
> (Optionally) Move libprocess/stout to the top-level directory.
> 
> I wanted to start some discussion around reorganizing stuff inside
> "3rdparty". I apologize for the length of the email, please bear with
>>> me.
> 
> Traditionally, 3rdparty has been used to hold all Mesos dependencies
> (zookeeper, libprocess, protobuf, stout, etc.). Further,
> libprocess/3rdparty was to hold all libprocess dependencies (which may
>>> in
> turn be Mesos dependencies as well).
> 
> As I understand, the original motivation was to emphasize that
>>> libprocess
> is an independent project which depends on "stout", which in turn is
>>> also
> an independent project.
> 
> However, in the current code base, we don't strictly follow the
>>> 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages 

Re: Precision of scalar resources

[Alexander Rojas]

+1

Strong initial first step to remove a huge headache.

> On 12 Feb 2016, at 14:25, Neil Conway  wrote:
> 
> Additional precision in resource values will be discarded
> (via rounding).

Re: Version numbers in docs

[Alexander Rojas]

I actually like the idea to have version specific documentation, since it is 
kind of the standard way of going about things.

+1 to that.


> On 03 Feb 2016, at 01:53, Neil Conway  wrote:
> 
> I agree we should remove this text after some period of time has
> passed since that version of Mesos was released; it is quite
> distracting.
> 
> The proper long-term fix is probably to have version-specific docs. So
> all the documentation at
> 
> /documentation/v0.27/...
> 
> would implicitly discuss the features that are present in Mesos 0.27.
> That would eliminate a lot of the need for version number references
> in the documentation text itself.
> 
> Neil
> 
> On Tue, Feb 2, 2016 at 4:48 PM, Greg Mann  wrote:
>> Hi all!
>> In our docs, you find such sentences as:
>> 
>> "Mesos 0.15.0 added support for framework authentication, and 0.19.0 added
>> slave authentication."
>> 
>> It's a minor point, but I wonder how long we should maintain such version
>> numbers in the docs? In the example above, my feeling is that we are far
>> enough past 0.19.0 that we could change this to read simply, "Mesos
>> supports authentication of both frameworks and slaves".
>> 
>> Thoughts?
>> 
>> Cheers,
>> Greg

Re: .gitignore-template

[Alexander Rojas]

It certainly is not unwittingly unless you are one of those who do `git yolo` 
and we should really discourage such dangerous way of writing patches. Once you 
do git status you will notice there is something wrong with the template.

That being said, +1 to add this to the documentation. These caveats should be 
mentioned for newcomers.

> On 28 Jan 2016, at 17:06, Marco Massenzio  wrote:
> 
> On Thu, Jan 28, 2016 at 3:18 AM, Michael Park  wrote:
> 
>> This has been done here:
>> https://github.com/apache/mesos/commit/16c62e5965f304ba59f26f4dbe0bcdfaded7c5ae
>> 
> 
> ​Unless I'm missing something fundamental here, this means that anyone who
> decides to add some pattern to the /.gitignore file (assuming they
> don't realize it's a symlink and just go `vim .gitignore`) will add those
> changes
> (unwittingly) to `support/gitignore` - changes that will end up in the
> patch.
> 
> I would recommend we add appropriate documentation in the "getting started"
> or "contributing to mesos" guides, as this may catch folks new to the
> project off-guard.
> ​
> 
> 
>> 
>> 
>> On 20 January 2016 at 21:02, Marco Massenzio 
>> wrote:
>> 
>>> +1 for consistency
>>> 
>>> Just a quick note to point out that if you _symlink_ .gitignore, then any
>>> changes folks make to that file (to customize to their needs, eg, ignore
>>> IDE-specific files etc.) would unwittingly become diffs to
>>> .gitignore_template.
>>> 
>>> A possible alternative may be to _copy_ .gitignore_template to .gitignore,
>>> so that local changes stay that way (as we already ignore .gitignore).
>>> The obvious downside is that changes to the _template do not get reflected
>>> to the .gitignore copy; but those are rare enough that we can easily
>>> address them by dropping an email to this list, perhaps?
>>> 
>>> (and, yes, using a global ~/.gitignore is a great strategy, but there may
>>> be cases in which it may not be possible/desirable)
>>> 
>>> I'm easy either way and don't mind whichever we choose; just pointing out
>>> a
>>> possible issue.
>>> 
>>> --
>>> *Marco Massenzio*
>>> 
>>> http://codetrips.com
>>> 
>>> On Wed, Jan 20, 2016 at 8:20 PM, Avinash Sridharan >> wrote:
>>> 
 +1 MPark
 
 Thanks Kevin for the tip. Found it useful !!
 
 On Wed, Jan 20, 2016 at 3:48 PM, Kevin Klues  wrote:
 
> +1 for Consistency!
> 
> As a side note, I add custom .gitignore stuff in a global .gitignore
> file I install at ~/.gitignore.  This is useful for ignoring things
> specific to editor temporary files (e.g. *.swo in vim), etc.
> 
> you can make git aware of it via:
> $ git config --global core.excludesfile ~/.gitignore
> 
> On Wed, Jan 20, 2016 at 3:45 PM, Michael Park 
>>> wrote:
>> We have a few other default templates such as `support/clang-format`
 and
>> `support/reviewboardrc`, and `bootstrap` symlinks them to
 `.clang-format`
>> and `.reviewboardrc` respectively.
>> 
>> To keep this pattern consistent, I would like to move the
>> `.gitignore-template` template to `support/gitignore` and have
> `bootstrap`
>> symlink it to `.gitignore`.
>> 
>> Please let me know if you're opposed to this change.
>> 
>> Thanks!
>> 
>> MPark.
> 
> 
> 
> --
> ~Kevin
> 
 
 
 
 --
 Avinash Sridharan, Mesosphere
 +1 (323) 702 5245
 
>>> 
>> 
>> 

Re: JIRA Shepherds

[Alexander Rojas]

My grain of sand here. It is true that committers are a scare resource and it 
might be hard to get shepherds nowadays. However we do have a bunch of seasoned 
contributors, which while not being committers are active and know some of the 
innards of Mesos very well. How about having these guys as shepherds?

At the end a committer may be required to sign off a project, but all the work 
of communicating with the contributor, come up with a design could be lifter 
off from committers?

What do you guys thing about the idea?


> On 27 Jan 2016, at 00:29, Vaibhav Khanduja  wrote:
> 
> The community is growing with more individuals getting interested in
> contributing to the project. This definitely brings an extra bit of
> workload for committers “Shepherds” but at the same time more developers
> eventually leads more adoptability across organization and enterprises.
> 
> 
> 
> I am not sure if this is easy to find an immediate solution but would
> really like some sort of resolution on this. If shepherd is busy, what else
> can be done for a low priority but a genuine issue.
> 
> On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
> joris.van.remoort...@gmail.com> wrote:
> 
>> Hello Mesos developers,
>> 
>> You may have noticed some churn in Jira recently around the shepherd
>> assignment. Specifically, we have unassigned the shepherds for a bunch of
>> projects. We did this in order to get a better sense of which projects are
>> being actively shepherded versus having gone stale, and to identify for
>> which projects we need to find a new shepherd who has sufficient time to
>> dedicate to it.
>> 
>> This is not a statement that the un-assigned tickets are not important,
>> rather, we want to ensure that the people working on them have a shepherd
>> with sufficient resources.
>> 
>> We ask that you communicate (and agree!) with your shepherd before
>> assigning them in Jira, so that they are not surprised when you reviews
>> start getting posted.
>> 
>> The benefit for the developer community should be that it will be more
>> clear when working on a ticket whether there are sufficient resources in
>> the community to iterate on it in a timely manner.
>> 
>> Joris
>> 

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

[Alexander Rojas]

-1 (non binding)

Test on Debian 8 under a VirtualBox debian machine. While doing

`configure && sudo make -j4 check`

and then:

`sudo ./bin/mesos-tests.sh 
--gtest_filter=“-*.ROOT_CGROUPS_Listen:*.ROOT_IncreaseRSS" --gtest_repeat=10 
--gtest_break_on_failure`

I got failures on DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping and 
NetClsIsolatorTest.ROOT_CGROUPS_NetClsIsolate.

The first had a JIRA entry but was marked as resolved in 0.26.0 with a cannot 
reproduce. The second didn’t have any issues open.

My -1 vote will stand until the failing tests are decidedly non blockers for 
the release.

> On 27 Jan 2016, at 07:53, Timothy Chen  wrote:
> 
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 0.27.0.
> 
> 0.27.0 includes the following:
> 
> We added major features such as Implicit Roles, Quota, Multiple Disks and 
> more.
> 
> We also added major bug fixes such as performance improvements to
> state.json requests and GLOG.
> 
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc1
> 
> 
> The candidate for Mesos 0.27.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz
> 
> The tag to be voted on is 0.27.0-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc1
> 
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.md5
> 
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.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-1097
> 
> Please vote on releasing this package as Apache Mesos 0.27.0!
> 
> The vote is open until Fri Jan 29 23:59:59 PST 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Mesos 0.27.0
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> 
> Tim, MPark and Kapil

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

[Alexander Rojas]

While valid, I feel that is a very un-unix way of doing this. There are a 
couple of ideas from me here.

1. We should separate between a dev release and a normal release. The dev 
release will include headers for people who want to build modules and other 
mesos stuff, and the normal release only includes the executables.
2. When building Mesos, we should avoid exporting unnecessary symbols. This 
happens to me when building a framework which used a newer version of boost, 
but when trying to link to mesos, it was taken boost symbols from Mesos, rather 
annoying (I gave up at the end). I had this problem in the past but I just 
cannot remember how it was solved.

With respect to Alex issue, I don’t see them as much of a problem as long as we 
keep the standard behavior of the `--prefix` flag, which allows installation of 
different versions in different directores.


> On 26 Jan 2016, at 19:54, Kapil Arya  wrote:
> 
> Thanks for the feedback, Alex! I have inlined my responses.
> 
>> First, I think we should support two use cases: installing 3rdparty
>> packages and exposing them in the local build. As a Mesos (module)
>> developer, I may have different versions of Mesos on my machine and I
>> install neither of them to avoid conflicts. If I develop a module for a
>> particular Mesos version (i.e. build), I would like to use artifacts of
>> that build without installing them anywhere.
> 
> That's a valid use case. How about "installing" the 3rdparty packages
> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
> modules? We can also update libprocess/Mesos to also use these
> locations instead of passing a dozen "-I" and "-L" flags during
> compilation. I am guessing this won't be too intrusive to the overall
> build system.
> 
>> Second, additionally 3rdparty packages, how about modules we provide with
>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>> refactor default implementations into modules (e.g. hierarchical
>> allocator), we should install them somewhere.
> 
> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
> for it :-). We should just install them in $(pkglibdir). That's the
> default location for distro packaging as well. That's not too hard to
> do. Just that we need to decide which modules should be installed.
> 
> Best,
> Kapil
> 
> 
>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
>> 
>>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
>>> wrote:
 Great thinking, Kapil!
 (I'm one who got the headache :)
 
 However, having recently gone through the effort of having to figure out
>>> it
 all, my +1 goes for *good documentation* of what is necessary.
>>> 
>>> Totally with you on this :)
>>> 
>>> 
 When installing stuff / magic happening behind the scenes, it is always
 difficult to ensure it works on all "supported" platforms (and let's not
 even go into non-supported ones) and we would also run the risk that
>>> future
 changes may inadvertently break it.
 
 Bear also in mind that folks (who may not be using the --prefix) may be
 "surprised" to find incompatible/unexpected versions of
>>> glog/protobuf/etc.
 in the /usr/local system dir.
>>> 
>>> This is the reason why we want to put it inside Mesos "owned"
>>> directories (e.g., /usr/local/include/mesos/3rdparty,
>>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>>> free for other applications/packages installed on the system.
>>> 
 We could also provide "exemplary scripts" that automate (most of) the
 tedious work and example build files, alongside documentation.
 If folks agree that this is a desirable alternative, I'm happy to help
>>> out
 - as mentioned, I've recently been through this, so memory is still
>>> fresh.
>>> 
>>> I think several of us have developed such scripts by now. However, the
>>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>>> component is updated in Mesos :-/.
>>> 
 
 My 2c.
 
 --
 *Marco Massenzio*
 http://codetrips.com
 
 On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya 
>>> wrote:
 
> On Tue, Jan 19, 2016 at 11:58 PM, James Peach  wrote:
>> 
>>> On Jan 19, 2016, at 2:03 PM, Kapil Arya  wrote:
>>> 
>>> Hi All,
>>> 
>>> I wanted to get your opinion on installing the 3rdparty packages
>>> glog,
>>> protobuf, boost and picojson[1] when installing Mesos itself. These
>>> packages are required to build Mesos modules.
>> 
>> An alternative approach could be to hide these headers so they are
> internal to Mesos and not incidentally required by innocent modules.
>>> IIRC
> this should be fairly 

Re: Contribution Request

[Alexander Rojas]

Hey guys,

There is already a flag called `authenticate_frameworks` which was added as 
early as April 2015, it also includes a TODO pointing to the mentioned JIRA 
(MESOS-4386). So I think enough time has passed to simply remove the flag.

Best,

Alexander

> On 15 Jan 2016, at 19:15, Vinod Kone  wrote:
> 
> Hi Disha,
> 
> Thanks for asking.
> 
> We cannot just rename the `authenticate` flag to `authenticate_frameworks`
> because that will break users who are already setting that flag, when they
> upgrade to the new version (that has this change). We always strive to do
> backwards compatible changes.
> 
> The first step is to add a new flag called `authenticate_frameworks` flag
> and make sure the master does the same thing as when `authenticate` flag is
> set. As part of this we need to 1) send an email to dev/user mailing lists
> that this deprecation is coming and 2) update the CHANGELOG. Lets say this
> all happens in the 0.28 release. After a few releases (to give
> users/operators enough time), we can remove the `authenticate` flag.
> 
> Does that make sense?
> 
> 
> On Fri, Jan 15, 2016 at 9:55 AM, Disha Singh 
> wrote:
> 
>> MESOS-4386 says :
>> 
>> <<> flags, we should rename `authenticate` to `authenticate_frameworks` flag.
>> 
>> This should be done via deprecation cycle.
>> 
>> 1) Release X supports both `authenticate` and `authenticate_frameworks`
>> flags
>> 
>> 2) Release X + n supports only `authenticate_frameworks` flag.
>> 
>> How should I move ahead with resolving it ? Does it simply mean changing
>> the word "authenticate" to authenticate frameworks ? I am a newbie .Please
>> help. :)
>> 
>> 
>> On Fri, Jan 15, 2016 at 11:07 PM, Artem Harutyunyan 
>> wrote:
>> 
>>> Done. Welcome to Mesos community!
>>> 
>>> On Fri, Jan 15, 2016 at 9:26 AM, Disha Singh 
>>> wrote:
 Please add me to the list of Mesos contributors. I would like to
>> submit a
 code review for the following JIRA:
 
>>> 
>> 

Re: Mesos build & testing environment instructions

[Alexander Rojas]

+1 This would be really helpful

> On 17 Dec 2015, at 21:38, Greg Mann  wrote:
> 
> reparation for the 0.26.0 release. Since I started contributing
> to the project, my Source of Truth for "how to prepare a given platform to
> compile and run Mesos" has been the Getting Started page of our
> documentation. However, this doc doesn't provide guidance for all platforms
> on "how to prepare this platform to compile Mesos and then TEST it in all
> configurations", which is crucial information for us when it comes to
> testing, and would be useful to our users as well. I wonder if it makes
> sense to have a separate place in our documentation where we include these
> exhaustive installation instructions, which 

Re: Change minimum supported version for GCC to 4.8.1

[Alexander Rojas]

+1

> On 05 Jan 2016, at 00:06, Anand Mazumdar  wrote:
> 
> I would like to propose that we bump our minimum supported version for gcc 
> from 4.8.0 to 4.8.1. The main motivation behind this is that there are at 
> least 2 outstanding reviews on RB that want to use ref-qualifiers 
>  
> introduced in GCC 4.8.1. The reviews in question are r41870 
>  and r41593 
> . 
> 
> Also, our Getting Started document  
> for Mesos already lists the minimum gcc version as > 4.8. Looking at the 
> release timeline  for GCC, it seems that 
> 4.8.0/4.8.1 were released within a week of each other.
> 
> Does anyone have a strong opinion against this change ?
> 
> -anand
> 
> 

Re: `F()` vs `F(void)`

[Alexander Rojas]

+1

> On 13 Dec 2015, at 19:46, Michael Park  wrote:
> 
> Hello,
> 
> In the C++ world, the *void* parameter is considered to be only there for C
> compatibility reasons.
> 
> We do a good job of not using *void *parameters in function declarations,
> e.g., *void F();*. On the other hand, we're *not* so good doing so for
> function types, e.g., *std::function*.
> 
> I would like to see the codebase converge to *not* use *void* as a
> parameter type, and would like feedback if anyone holds strong opposing
> opinions.
> 
> Thanks,
> 
> MPark.

Re: Can anyone help me understand the Mesos release model

[Alexander Rojas]

Hi Zhiweik,

As far as I know it works like this. You take a branch at some point, lets say 
2da4db5, then you branch at that point and create the release doc, if necessary 
you cherry-pick some patches which are needed for the release, at that point 
the heads of master and your temporary branch have diverged. When you’re 
satisfied with your rc, you push the tag but don’t push the branch (though 
implicitly it does, the becomes effectively an anonymous branch in the git main 
repository).

Repeat the procedure for the next releases.

Best,

Alexander Rojas

> On 09 Dec 2015, at 11:49, zhiwei <zhiw...@gmail.com> 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?

Configuration file?

[Alexander Rojas]

Hey guys,

Over the time I’ve been involved in Mesos I’ve seen that we went from a handful 
of flags to around 42 supported flags in the master. At this point I’m 
wondering if perhaps we should support a configuration file in conjunction (or 
instead of) with all the command flags.

My intuition is that it will make it easier for operators as well as for 
debuggers to be able to replicate configurations easier.

Any comments on this idea?

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

[Alexander Rojas]

+1

This also provides a way of removing TODO’s since they are traceable. If you 
look in the code, there are TODO’s which are no relevant anymore or probably 
cannot be understood from their actual context.

> On 08 Nov 2015, at 05:50, Kapil Arya  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

Re: Header include order

[Alexander Rojas]

I remember discussing this issue a while ago on the mailing list [1]. There 
were two votes in favor from Benjamin Hindman and Benjamin Mahler, and no votes 
against it. There’s also an accepted Jira entry MESOS-2673 to add the ordering 
into our style guide.

[1] 
http://mail-archives.apache.org/mod_mbox/mesos-dev/201505.mbox/%3ccadcam2slfjl2h4wvxjxbpxgykfxfs3ciccfpwk_3q4q-6mt...@mail.gmail.com%3E
 

> On 10 Nov 2015, at 17:35, Jan Schlicht  wrote:
> 
> Currently there is no consensus on the order of includes. I'm currently
> working on MESOS-2275 and would suggest, that we follow the rules from the
> Google C++ Style Guide (
> https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes)
> as much as possible but also follow the current grouping of includes by
> their level of indirection.
> 
> One important question that came up on RR (
> https://reviews.apache.org/r/39449/) is, if we should include the "related
> header" of a source file first. Currently this header is included like any
> other header. How about we should change that practice and include this
> header first to avoid hidden dependencies?
> 
> -- 
> *Jan Schlicht*
> Distributed Systems Engineer, Mesosphere

Re: Fetcher refactor proposal

[Alexander Rojas]

+1

> On 11 Nov 2015, at 00:45, Jie Yu  wrote:
> 
> Hi,
> 
> Fetcher was originally designed to fetch CommandInfo::URIs (e.g., executor
> binary) for executors/tasks. A recent refactor (MESOS-336
> ) added caching support to
> the fetcher. The recent work on filesystem isolation/unified containerizer (
> MESOS-2840 ) requires
> Mesos to fetch filesystem images (e.g., APPC/DOCKER images) as well. The
> natural question is: can we leverage the fetcher to fetch those filesystem
> images (and cache them accordingly)? Unfortunately, the existing fetcher
> interface is tightly coupled with CommandInfo::URIs for executors/tasks,
> making it very hard to be re-used to fetch/cache filesystem images.
> 
> Another motivation for the refactor is that we want to extend the fetcher
> to support more types of schemes. For instance, we want to support magnet
> URI to enable p2p fetching. This is in fact quite important for operating a
> large cluster (MESOS-3596 ).
> The goal here is to allow fetcher to be extended (e.g., using modules) so
> that operators can add custom fetching support.
> 
> I proposed a solution in this doc
> .
> The main idea is to decouple artifacts fetching from artifacts cache
> management. We can make artifacts fetching extensible (e.g. to support p2p
> fetching), and solve the cache management part later.
> 
> Let me know your thoughts! Thanks!
> 
> - Jie

Re: [jira] [Comment Edited] (MESOS-2079) IO.Write test is flaky on OS X 10.10.

[Alexander Rojas]

I have multiple questions here

1. Why do we use pipes at all? or is SIGPIPE raised also when writing into 
sockets? which leads me to:
2. Do we use it only in test cases or is there something actively using pipes?

SIGPIPE itself is a weird signal, since a failed call to `write` returns -1 and 
sets `errno` to `EPIPE` so there are two ways to deal with errors when the 
reading process is not longer reading, one is handling the return value+errno 
(which usually means ignoring the SIGPIPE) and the second is ignoring the 
return value and handling SIGPIPE. The difference is that SIGPIPE is raised as 
soon as the OS realizes the pipe is broken while the error on the write happens 
when you actually try to write on the pipe.

All in all, I prefer to ignore the signal and deal with the return value of 
`write`.

> On 06 Nov 2015, at 03:27, Benjamin Mahler  wrote:
> 
> Just want to surface this up to the dev@ thread to raise some awareness.
> Recently with the SIGPIPE bug from libev [1], we've revisited whether it
> makes sense to continue down the path of leaving SIGPIPE unblocked and
> trying to handle it case by case.
> 
> We originally wanted users of libprocess to decide on their own whether
> they want to ignore SIGPIPE. However, we'd like to reconsider:
> 
> (a) The amount of code that is needed to work around SIGPIPE is
> substantial, especially because on OS X SIGPIPE appears to not be delivered
> synchronously [2]. Also, it is not possible to create pipes that don't
> surface SIGPIPE (unlike sockets), so in order to safely write to a pipe we
> need to wrap write() calls with signal suppression blocks (which we don't
> do in general!). You can get a sense of the code from [3] and [4].
> 
> (b) SIGPIPE seems to be more of a legacy mechanism to shut down a set of
> piped programs and the general recommendation seems to be to not bother
> with it and ignore it. Programs can handle EPIPE as they would with other
> signals.
> 
> Would love to hear if there are any concerns. I will be glad to shepherd
> James' changes here.
> 
> [1] https://issues.apache.org/jira/browse/MESOS-2768
> [2] https://issues.apache.org/jira/browse/MESOS-2079
> [3] https://reviews.apache.org/r/39940/diff/1#index_header
> [4]
> https://github.com/apache/mesos/blob/0.25.0/3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/signals.hpp#L101
> 
> On Wed, Nov 4, 2015 at 9:20 AM, James Peach (JIRA)  wrote:
> 
>> 
>>[
>> https://issues.apache.org/jira/browse/MESOS-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989947#comment-14989947
>> ]
>> 
>> James Peach edited comment on MESOS-2079 at 11/4/15 5:19 PM:
>> -
>> 
>> These patches global ignore {{SIGPIPE}} during libprocess initialization,
>> document {{SIGPIPE}} behavior a bit more, and remove various signal
>> manipulations that were formerly necessary for disabling {{SIGPIPE}}
>> delivery.
>> 
>> https://reviews.apache.org/r/39938/
>> https://reviews.apache.org/r/39940/
>> https://reviews.apache.org/r/39941/
>> 
>> 
>> 
>> was (Author: jamespeach):
>> https://reviews.apache.org/r/39938/
>> https://reviews.apache.org/r/39940/
>> https://reviews.apache.org/r/39941/
>> 
>> 
>>> IO.Write test is flaky on OS X 10.10.
>>> -
>>> 
>>>Key: MESOS-2079
>>>URL: https://issues.apache.org/jira/browse/MESOS-2079
>>>Project: Mesos
>>> Issue Type: Task
>>> Components: libprocess, technical debt, test
>>>Environment: OS X 10.10
>>> {noformat}
>>> $ clang++ --version
>>> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
>>> Target: x86_64-apple-darwin14.0.0
>>> Thread model: posix
>>> {noformat}
>>>   Reporter: Benjamin Mahler
>>>   Assignee: James Peach
>>> Labels: flaky
>>> 
>>> [~benjaminhindman]: If I recall correctly, this is related to
>> MESOS-1658. Unfortunately, we don't have a stacktrace for SIGPIPE currently:
>>> {noformat}
>>> [ RUN  ] IO.Write
>>> make[5]: *** [check-local] Broken pipe: 13
>>> {noformat}
>>> Running in gdb, seems to always occur here:
>>> {code}
>>> Program received signal SIGPIPE, Broken pipe.
>>> [Switching to process 56827 thread 0x60b]
>>> 0x7fff9a011132 in __psynch_cvwait ()
>>> (gdb) where
>>> #0  0x7fff9a011132 in __psynch_cvwait ()
>>> #1  0x7fff903e7ea0 in _pthread_cond_wait ()
>>> #2  0x00010062f27c in Gate::arrive (this=0x101908a10, old=14780) at
>> gate.hpp:82
>>> #3  0x000100600888 in process::schedule (arg=0x0) at
>> src/process.cpp:1373
>>> #4  0x7fff903e72fc in _pthread_body ()
>>> #5  0x7fff903e7279 in _pthread_start ()
>>> #6  0x7fff903e54b1 in thread_start ()
>>> {code}
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>> 

Re: Backticks in comments

[Alexander Rojas]

+1 for backticks!

> On 02 Nov 2015, at 19:32, Greg Mann  wrote:
> 
> Hey folks!
> I wanted to bring up a style issue that I noticed recently. In some
> comments in the codebase, backticks are used to quote code excerpts and
> object names, while in other comments, single quotes are used. This doesn't
> seem to be documented in our style guide (nor in Google's), and I think it
> would be a good idea to establish a policy on this and document it, so that
> we can avoid wasted review cycles related to this in the future.
> 
> It's likely that the backtick convention began because Doxygen will render
> backtick-enclosed text in monospace, and for this reason I would propose
> that we consistently use backticks to quote code excerpts and object names
> in comments from now on. What does everyone else think?
> 
> Cheers,
> Greg

Re: Better error reporting in Mesos

[Alexander Rojas]

I also like the idea of having better error reports. On that side, I always 
liked the design of boost system_error where one has categories of errors with 
a set of error codes (integer) where each of them have a specific string 
associated and which can be complemented with extra text.


> On 06 Nov 2015, at 09:29, Michael Hopcroft  wrote:
> 
> Error reporting in Mesos is based on Stout’s Error class and a variety of
> other classes, such as ErrnoError and WindowsError, that derive from Error.
> One goal of these classes is to simplify the construction and storage of
> error message strings. As an example, the ErrnoError constructor
> automatically incorporates std::string(strerror(errno)) into its error
> message.
> 
> 
> Stout catches exceptions and converts them into Try  and Result
> objects which are used as polymorphic return values that can express either
> an error condition or a proper return value. One consequence of catching
> exceptions is that call stacks from throw sites and error sites are lost.
> This makes it harder to debug production environment crashes post hoc.
> 
> 
> One way to improve debugability would be to add more information about the
> error site to the error message. This could be done by convention, but it
> seems that the vast majority of the error messages in Mesos currently don’t
> include much information about the site that originally generated an error.
> 
> 
> Because much of the code in Mesos uses Error and ErrnoError, we have an
> opportunity to add diagnostic information automatically with only a small
> amount of churn. What we’d need to do is provide Error creation macros that
> would pass the source file name and line number to the constructors of the
> various Error classes.
> 
> 
> Concretely this would involve
> 
> 
>   - class Error
>  - Rename declaration and definition to ErrorImpl (or ErrorBase). This
>  change is not error prone.
>  - Rename references to class’ type. These changes are mostly limited
>  to result.hpp and try.hpp.
>  - Don’t rename calls to constructor. These will now just invoke the
>  macro.
>  - Modify the constructor to take a line number and source filename in
>  addition to a message.
>  - Define a macro called Error(message) that has the same prototype as
>  the original Error constructor. This macro would invoke
>  ErrorImpl::ErrorImpl, passing the current line number and source filename
>  along with the user-provided message. The macro would make use
> of __FILE__
>  and __LINE__, which are predefined in gcc and Visual Studio.
>   - class ErrnoError, WindowsError.
>  - Similar pattern as above.
> 
> *Pros.*
> 
> 
>   - Codebase is more debuggable in production environment because the vast
>   majority of error sites will document the file name and line number in the
>   error message.
>   - Most error sites don’t require a code change.
> 
> *Cons.*
> 
> 
>   - Introduces a macro. In general, we’d like to move away from macros
>   wherever possible.
>   - Discourages subclassing of Error because each subclass would need its
>   own special macro to call its constructor. A brief search of the code base
>   seems to indicate that Mesos programmers don’t tend to declare subclasses
>   of Error. Right now, it seems that subclasses exist mainly to provide
>   different construction semantics. The big question is whether one would
>   want to use subclasses down the road to distinguish between equivalence
>   classes of errors, say those that should bring the process down vs those
>   that are recoverable.
>   - Some amount of code churn, mainly in error.hpp, result.hpp, and
>   try.hpp.
> 
> *Limitations.*
> 
> 
>   - This approach by itself won’t address error sites that invoke
>   convenience functions such as Try::error() and Result::error(). These
>   could be addressed with a similar macro, but it would need to somehow deal
>   with the template parameter as well.
> 
> *Risks and Potential Complications.*
> 
> 
>   - The rename process might fail to correctly distinguish between error
>   sites (i.e. calls to Error::Error()) and other uses of the term “Error”.
>   - There may be important compilers that don’t support __FILE__ and
>   __LINE__. These predefined macros have been in the ANSI/ISO standard for a
>   while, but it would still be wise to check each compiler we care about.
>   - General hazards associated with macro expansion.
>   - Users of Mesos may have written diagnostic tools that depend on the
>   current values of the error strings.
>   - Unit tests may depend on exact values of error strings. If this were
>   the case, we'd have to provide a convenience function that strips off the
>   file names and line numbers so that unit tests don't break when error sites
>   move around due to edits elsewhere in the file.
> 
> Let me know what you think of this idea. If the approach seems reasonable
> and a worthwhile, I would be willing to 

Re: Mesos Style Guideline Adjustments

[Alexander Rojas]

>> 
>>>>>>> +1
>>>>>>> (it really IS annoying having to keep an eye on the bottom column
>>>>> counter
>>>>>>> when typing comments :)
>>>>>>> 
>>>>>>> 
>>>>>>>> -1 on sweeping changes; incremental changes when touching old
>>> comments
>>>>>>>> will do IMHO
>>>>>>>> 
>>>>>>>> +1 on the -1? :)
>>>>>>> Incremental changes are good and I doubt anyone will be "confused"
>> by
>>>>> them.
>>>>>>> 
>>>>>>> 
>>>>>>>> Bernd
>>>>>>>> 
>>>>>>>>> On Aug 12, 2015, at 12:51 AM, Michael Park <mcyp...@gmail.com>
>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Ben, thanks for your input!
>>>>>>>>> 
>>>>>>>>> Another update on this topic: the patches around break before
>> braces
>>>>>>> for
>>>>>>>>> *enum* style and overloaded operators have been committed.
>>>>>>>>> 
>>>>>>>>> On Tue, Aug 11, 2015 at 6:23 PM Benjamin Mahler <
>>>>>>>> benjamin.mah...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> We already don't necessarily wrap at 70 characters (often we wrap
>>>>>>>> before 70
>>>>>>>>>> to reduce "jaggedness" or to make it look cleaner).
>>>>>>>>>> 
>>>>>>>>>> So with the change to 80, this still makes all existing comments
>>>>>>> valid.
>>>>>>>> We
>>>>>>>>>> can still encourage folks to write paragraphs in a way that is
>>>>> easy to
>>>>>>>>>> digest for the reader. That is, I think we should still be trying
>>>>> not
>>>>>>> to
>>>>>>>>>> write jagged paragraphs of comments, it's just not a hard
>> stylistic
>>>>>>>>>> violation given we don't have an algorithm for this.
>>>>>>>>>> 
>>>>>>>>>> So +1 to relaxing the hard 70 character rule, but -1 to sweeping
>>>>>>> across
>>>>>>>> all
>>>>>>>>>> the comments or doing wrapping based only on line length rather
>>>>> than
>>>>>>>>>> jaggedness going forward.
>>>>>>>>>> 
>>>>>>>>>> On Sat, Aug 8, 2015 at 3:25 PM, Joris Van Remoortere <
>>>>>>>> jo...@mesosphere.io>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> I will volunteer to update all the comments to wrap at 80 if we
>>>>> agree
>>>>>>>> to
>>>>>>>>>>> keep the code base consistent.
>>>>>>>>>>> Naturally that is also my vote ;-)
>>>>>>>>>>> Joris
>>>>>>>>>>> 
>>>>>>>>>>>> On Aug 8, 2015, at 1:40 PM, Michael Park <mcyp...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> An update on this topic since we covered it at the community
>>>>>>> developer
>>>>>>>>>>> sync.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. We will adopt *Mozilla*'s *BreakBeforeBraces* style as their
>>>>>>> style
>>>>>>>>>>> is
>>>>>>>>>>>> equivalent to ours. The only change this entails for our
>>>>> codebase
>>>>>>> is
>>>>>>>>>> to
>>>>>>>>>>>> consistently wrap the braces for *enum* definitions, as we're
>>>>>>>>>> currently
>>>>>>>>>>>> inconsistent. I've taken on the work involved in this change:
>>>>>>>>>>>>   - stout: https://reviews.apache.org/r/37258
>>>>>>>&g

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

[Alexander Rojas]

While I’m all in on the proposal, we did have this discussion almost a year ago 
[1] at the end I think, the decision was not to use them, though I don’t 
remember the exact reason. In any case, I vote +1 non-binding.

[1] 
http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E
 



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

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

[Alexander Rojas]

my fault, I started reading at the office and when I came home I thought I had 
already read your whole email. Still, I have always been in favor or the 
`#pragma once` solution. So as I said:

+1 (non-binding).

> On 05 Nov 2015, at 18:21, Alex Clemmer <clemmer.alexan...@gmail.com> wrote:
> 
> Just because I apparently was not very clear: in the "history" and
> "summarized objections" sections of my original mail, I did attempt to
> capture all of the objections from this thread and previous
> discussions I found (and, just for the sake of thoroughness, I do
> actually explicitly cite this thread in the footnotes). If you don't
> want to dig through the thread yourself, I hope that this will give
> you a good approximation of what happened in that thread.
> 
> I see now that I did fail to mention that this thread ended in
> nonconsensus rather than an explicit decision against. Sorry about
> that. You can also see evidence that the decision was nonconsensus
> directly in the JIRA issues and the review I cite -- for example on
> JIRA, Alex R mentions removing the newbie tag from the issue because
> there is nonconsensus, and the review was discarded, with the cited
> reason being nonconsensus.
> 
> Hopefully this clarifies these issues.
> 
> On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas <alexan...@mesosphere.io> 
> wrote:
>> While I’m all in on the proposal, we did have this discussion almost a year 
>> ago [1] at the end I think, the decision was not to use them, though I don’t 
>> remember the exact reason. In any case, I vote +1 non-binding.
>> 
>> [1] 
>> http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E
>>  
>> <http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E>
>> 
>> 
>>> On 05 Nov 2015, at 06:36, Alex Clemmer <clemmer.alexan...@gmail.com> wrote:
>>> 
>>> Hey folks.
>>> 
>>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>>> brought up the issue of moving away from #include guards and towards
>>> `#pragma once`.
>>> 
>>> As this has been brought up before, I will be brief: we think it's
>>> revisiting because the primary objection in previous threads appears
>>> to be that, though `#pragma once` is a cleaner solution to the
>>> multiple-include problem, it's not so much better that it's worth the
>>> code churn. However, the ongoing Windows integration work means we
>>> have to touch these files anyway, so if we agree this is cleaner and
>>> desirable, then this is an opportunity to obtain that additional code
>>> clarity, without the cost of the churn.
>>> 
>>> For the remainder of the email, I will summarize the history of our
>>> discussion of this issue, who will do the work, and what the next
>>> steps are.
>>> 
>>> PROPOSAL: We propose that all new code use `#pragma once` instead of
>>> #include guards; for existing files, we propose that you change
>>> #include guards when you touch them.
>>> 
>>> HISTORY: This has been discussed before, most recently a year ago on
>>> the mailing list[2]. There is a relevant JIRA[3] and discarded
>>> review[4] that changes style guide's recommendation on the matter.
>>> 
>>> SUMMARIZED OBJECTIONS:
>>> 1. The Google style guide explicitly forbids `#pragma once`.
>>> 2. This results in a lot of code churn, but is only marginally better.
>>> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
>>> doesn't support it.
>>> 4. Popular projects like Chrome don't do `#pragma once` because of
>>> history clutter.
>>> 5. Intermediate state of inconsistency as we transition to `#pragma
>>> once` from #include guards.
>>> 
>>> OUR RESPONSE:
>>> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
>>> points out in a previous thread that the Google style guide was
>>> canonized when `#pragma once` was Windows-only, and the guidance has
>>> not changed since because of the history churn problem. As noted
>>> above, we think the history churn problem is minimized by the fact
>>> that it can be wrapped up into the Windows integration work.
>>> 
>>> For objection (3), the consensus seems to be that the vast majority of
>>> compilers we care about (in particular, the ones supporting C++ 11) do
>>> support it.
>>> 
>>> F

Re: Welcome Kapil as Mesos committer and PMC member!

[Alexander Rojas]

Congrats Kapil. This is really worth to be celebrated.

> On 05 Nov 2015, at 11:02, Till Toenshoff  wrote:
> 
> I'm happy to announce that Kapil Arya has been voted a Mesos committer and 
> PMC member!
> 
> Welcome Kapil, and thanks for all of your great contributions to the project 
> so far! 
> 
> Looking forward to lots more of your contributions!
> 
> Thanks
> Till

Re: More Project Structure in JIRA

[Alexander Rojas]

+1 Yes please!

> On 15 Oct 2015, at 10:11, Bernd Mathiske  wrote:
> 
> Proposal: in extension of today’s limited two-level (epic, task) approach, 
> make full use of expressive power already available in JIRA to provide more 
> structure for larger projects to facilitate planning, tracking, and 
> reporting. This will facilitate dynamically planning of sub-projects, which 
> will make us more agile.
> 
> The general idea is to use links between epics to provide a recursive 
> hierarchical structure, with which one can span trees or DAGs of arbitrarily 
> large projects. This does not mean that we want to plan everything in minute 
> detail before starting to work. On the contrary.
> 
> You can start anywhere in the eventual tree and express part of the overall 
> effort, maybe say a short epic with a few task tickets. Then you can LATER 
> make this epic a dependency for a larger effort.
> 
> Conversely, you can subdivide a task in the epic into subtasks. However, this 
> does not mean that you have to literally use the feature “subtask” in JIRA 
> for this. Instead, staying recursive in our JIRA grammar, so to speak, 
> convert the task to an epic and then create ordinary tasks in it to represent 
> subtasks.
> 
> Now the task cannot be a task in its parent epic anymore. We fix this by 
> putting in a link of type "blocks" to the parent. When you then look at the 
> parent, it still holds a number of tasks, and it has one dependency on an 
> epic (to which you can add more).
> 
> Thus our dependency tree can grow in all directions. You can also rearrange 
> and update it in any shape or form if necessary.
> 
> Overall, we only use two JIRA elements: epics and tasks (of different flavors 
> such as bugs, improvements, etc.). Tasks are the leaves, everything else is 
> an epic. Review requests only ever happen for tasks.
> 
> The epics are there to provide a high level view and to allow dynamic (“more 
> agilish”, non-waterfall) planning. Granted, you’d also use a tree if you did 
> waterfall. The difference is that you’d spec it all out at once. My 
> observation is that not too few of us do exactly this - outside JIRA - and 
> then try to remember what tickets are where in their tree. Let’s make this 
> part of JIRA!
> 
> Why not use labels? Because they are in a flat name space and we want to 
> represent tree structure. How would you know that a label denotes a 
> subproject of another label? By memorizing or by depicting a tree outside 
> JIRA. Why not use components? Same problem as with labels: flat name space. 
> We can use labels and components these for many other purposes. Separate 
> discussion.
> 
> Aren’t we doing this already? Probably. I have not checked thoroughly. There 
> may occasionally be epics that link to other epics. If so, I would merely 
> like to encourage us to use this powerful expressive means more often.
> 
> Bernd
> 

Re: Community Sync Interval

[Alexander Rojas]

+1 bi-weekly (and I as bernd have been assuming rotating times)

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

Re: RFC convert documentation to Sphinx

[Alexander Rojas]

I would vote -1. There’s some cost associated with having to learn yet another 
documentation syntax, while almost all the tools we use easily support 
markdown. This feels a little like asking to use mercurial instead of git, sure 
it might be better at some stuff, but we will definitely find problems at some 
point, and honestly, when you check the amount of tools available, you have the 
feeling that md already won.

> On 03 Oct 2015, at 00:51, James Peach  wrote:
> 
> Hi all,
> 
> I'd like to discuss using Sphinx (http://sphinx-doc.org) for the Mesos 
> documentation.
> 
> Pros:
>   - you can generate HTML docs, PDF, single-page HTML
>   - you can generate man-pages for the user commands
>   - there's more markup
>   - supports indexing, cross-referencing and simple searching
>   - you can your own markup for cross-referencing and formatting
>   - it is easy to publish multiple version on readthedocs.org
> 
> Cons:
>   - not sure how the website integration would work
>   - there's more markup (more docs syntax to learn)
> 
> If there's interest (and a shepherd), then I'm willing to do the conversion.
> 
> cheers,
> James

Re: Introducing a CMake-based build system for Mesos

[Alexander Rojas]

Automation is always nice, but I think this is one of those cases where there’s 
not solution beyond updating guidelines and trusting the reviewers.

I recently faced another case of modifying a Makefile.am which didn’t need to 
update a CMakeLists.txt. If you add a stout test file, it needs to be added 
into the libprocess Makefile.am (the tests are running from there), but the 
stout CMake file is within stout.


> On 06 Oct 2015, at 14:58, Alex Rukletsov  wrote:
> 
> I'm thinking about how we can automate the process so we do not have a
> dependecy on a single human. I think if the build bot can run the test
> suite for both makefile and cmakelists and compare the outcome, this should
> suffice.
> On 4 Oct 2015 6:50 pm, "Alex Clemmer"  wrote:
> 
>> I like the idea, but sometimes it's not actually true that you want to
>> touch a CMakeLists when you touch a makefile.am. For example, headers
>> dependencies are automatically generated by CMake, so you don't have
>> to list the .hpp files. If you were only adding an hpp file to stout,
>> so this technique would make you change the CMakeLists even though you
>> don't actually want to. BTW, another thing to consider is that we also
>> need to find a way in general to tell people that if they modify a
>> configure script they likely need to modify a CMakeLists file as well.
>> 
>> So, for now I think it's fine that we have basically me going out and
>> reminding people manually.
>> 
>> Another thing worth thinking about on the horizon: it turns out
>> maintaining the CMake build is a bit more complicated than it might
>> seem. For example, adding simple changes to source files can break the
>> CMake build because it makes slightly different assumptions about how
>> to do things (like linking), so even if I monitor every review for
>> touching particular files, sometimes the build just breaks and I have
>> to find out why. We probably want to wrap CMake builds up into the
>> bulid bot tests so that contributors get used to it being a thing to
>> think about when you write code, and so the build doesn't just explode
>> randomly when I pull down from the master branch. I think Artem is
>> working on that.
>> 
>> On Wed, Sep 30, 2015 at 1:31 AM, Alex Rukletsov 
>> wrote:
>>> Can we extend a pre-commit hook in a way that it's not allowed to modify
>>> makefile.am without touching CMakeLists and that any new file should
>>> trigger touching CMakeLists? I think this can be part of reveiw r/38827.
>>> 
>>> On Tue, Sep 29, 2015 at 6:46 PM, Alex Clemmer <
>> clemmer.alexan...@gmail.com>
>>> wrote:
>>> 
 Just as an update, we have expanded support for building the agent,
 and there is a review up[1] to support a large part of the master.
 
 The work is still anchored to the Windows work, so we expect the rest
 of the CMake solution to materialize sporadically until the
 November/December timeframe. In the mean time, I will be haunting all
 your reviews, asking you to make your makefile.am/configure changes in
 CMakeLists files also. :) (For more complicated changes, I will even
 attempt to help you write the code myself!)
 
 In the meantime, if you have the time, it would be great to have more
 people try it on their favorite platform. We've tried it on Windows
 10, OS X 10.10, Ubuntu 14.04, and Ubuntu 15.04.
 
 [1] https://reviews.apache.org/r/38827/
 
 On Mon, Aug 10, 2015 at 12:13 PM, Alex Clemmer
  wrote:
> [... weeks later ...]
> 
> Alex, I think that's a great idea, actually! The module you have
> implemented is not a bad start. I've put it in a JIRA ticket so I
> don't lose track of it[1].
> 
> Also, just so we're clear: I'm not an expert at CMake. I wish I were,
> it would have made this whole thing much easier.
> 
> [1] https://issues.apache.org/jira/browse/MESOS-3249
> 
> On Wed, Jul 29, 2015 at 2:31 AM, Alex Rukletsov 
 wrote:
>> One related thing I have started to work on but have never polished
>> is
>> FindMesos CMake script. The prototype lives here:
>> 
 
>> https://github.com/rukletsov/mesos-modules/blob/master/cmake-modules/FindMesos.cmake
>> 
>> My original idea was to support not only system Mesos, but also
>> custom
>> builds, so that writers of Mesos Modules can use the script as well.
>> 
>> Alex, as CMake expert, let me know what you think!
>> 
>> On Mon, Jul 27, 2015 at 7:48 PM, Alex Clemmer <
 clemmer.alexan...@gmail.com>
>> wrote:
>> 
>>> Yes, CMake is currently checking if the -std=c++11 flag exists.
>> CMake
>>> 3 supports the autotools-style "feature check" style (which would be
>>> more appropriate on platforms like Windows, anyway) but it's not
>> clear
>>> how far back we want to support just yet -- right now we support
>> 

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

[Alexander Rojas]

+1 (non binding)

Tested Ubuntu 14.04, OSX

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

Re: [proposal] Generalized Authorizer Interface

[Alexander Rojas]

Hi Everyone,

After looking at your comments and doing some extra design we have updated the 
proposal for the Authorized Interface. Among the main changes is to remove the 
attributes of all the parameters and making the actions an enum. The full text 
can be found here:

https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit#heading=h.o4fbpp2hx411
 
https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit#heading=h.o4fbpp2hx411

Among the most recurrent question is how the change will be experience by users 
(operators and framework developers). So from their perspective, things won’t 
change unless using custom authorizers, and then only operators will notify one 
change: the load of the plugin for the custom authorizer.

I would like to listen from you guys on the proposal for recommendations in 
case we missed something.

Thanks,

Alexander Rojas


 On 06 Jul 2015, at 15:42, Alexander Rojas alexan...@mesosphere.io wrote:
 
 Hi everyone,
 
 The current mesos::Authorizer API has one method for each of the actions 
 supported (Register Framework, Launch Task and Shutdown Framework), and each 
 of 
 these actions define the objects on which they operate.
 
 Currently, if the Authorizer needs to be extended by adding a new action, it 
 is 
 necessary to modify the mesos::Authorizer interface and all its 
 implementations 
 (currently only mesos::LocalAuthorizer), and add a new nested message to the 
 ACL 
 message in mesos.proto.
 
 I want to propose a new version of the mesos::Authorizer interface which 
 allows
 implementations to offer any set of custom actions. It also hides 
 implementation
 details of how authorization is performed with the goal to allow for different
 authorization backends.
 
 The updated interface will look then like this:
 
class Authorizer {
public:
  virtual ~Authorizer() {}
 
  virtual process::Futurebool authorize(
  const OptionPrincipal principal,
  const Action action,
  const OptionObject object) = 0;
 
protected:
  Authorizer() {}
};
 
 Where Principal, Action and Object are protocol buffer generated objects 
 defined
 as:
 
message Principal {
  required string value = 1;
  repeated Parameter attributes = 2;
}
 
message Action {
  required string value = 1;
  repeated Parameter attributes = 2;
}
 
message Object {
  required string value = 1;
  repeated Parameter attributes = 2;
}
 
 The full text of the proposal can be found at
 https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit
 
 Note that Mesos users which defined ACLs through the --acls flags should not
 notice any change in behavior after the change.
 
 We’d love to get people’s feedback so we can move forward!
 
 Thanks,
 Alexander Rojas

Re: Mesos Contribution Request

[Alexander Rojas]

Hey Timothy,

Great to hear you are jumping into the ship. As Vinod pointed out, we are 
working already in an new HTTP based authentication design for Mesos. You can 
help us out be reading it and point out anything we had miss.


 On 05 Aug 2015, at 20:56, Timothy Anderegg timothy.ander...@gmail.com wrote:
 
 Thanks Vinod, I did see that, looks like a solid approach.  I'll continue
 to dig in and see where I can help.
 
 Tim
 
 On Wed, Aug 5, 2015 at 2:08 PM, Vinod Kone vinodk...@gmail.com wrote:
 
 Welcome Tim.
 
 This doc
 
 https://docs.google.com/document/d/1kM3_f7DSqXcE2MuERrLTGp_XMC6ss2wmpkNYDCY5rOM/edit#heading=h.bbxx6wwg3tpe
 
 might
 help you get a sense of the current state of authN and where it is going.
 
 On Wed, Aug 5, 2015 at 9:53 AM, Timothy Anderegg 
 timothy.ander...@gmail.com
 wrote:
 
 Yeah, I thought it was a good place to start :)  Thanks again!
 
 Tim
 
 On Wed, Aug 5, 2015 at 12:47 PM, Marco Massenzio ma...@mesosphere.io
 wrote:
 
 eh, contributing to documentation is the surest way of being loved by
 *any*
 OSS community :)
 
 There's a lot of activity currently around
 authentication/authorization,
 so
 I'm sure you'll have no trouble in finding stuff to contribute to.
 Thanks, Tim!
 
 *Marco Massenzio*
 *Distributed Systems Engineer*
 
 On Wed, Aug 5, 2015 at 9:35 AM, Timothy Anderegg 
 timothy.ander...@gmail.com
 wrote:
 
 Great, thanks Marco!  Ultimately I'm interested in helping with
 Kerberos
 authentication (would help with adoption of Mesos for us), but I'm
 planning
 to tackle some simpler things first as you suggest.  Right now I'm
 writing
 some of the authentication documentation, since that's missing
 currently
 (MESOS-1838), and will help prep me for more substantial work.
 
 -Tim
 
 On Wed, Aug 5, 2015 at 12:25 PM, Marco Massenzio 
 ma...@mesosphere.io
 wrote:
 
 Hi Tim,
 
 I've added you to the Contributors list, welcome to Apache Mesos
 and
 looking forward to your contributions!
 I assume you've obviously already looked up the Contributing page
 on
 mesos.apache.org and joined our Review Board (reviews.apache.org);
 the
 other one thing to look out for are tickets marked as 'newbie';
 they
 are
 usually a gentler introduction to our code base.
 
 Any other questions, please feel free to ask!
 Thanks for joining.
 
 *Marco Massenzio*
 *Distributed Systems Engineer*
 
 On Wed, Aug 5, 2015 at 7:57 AM, Timothy Anderegg 
 timothy.ander...@gmail.com
 wrote:
 
 Hello, I would like to get involved with the development of
 Mesos,
 my
 JIRA
 username is tanderegg, could I be added to the contributors list?
 Thanks,
 and let me know if you need any more info.
 
 Tim
 
 
 
 
 
 

HTTP Authentication Doc V1

[Alexander Rojas]

Hey Guys,

Lately the we have been working hard on figuring out the best way
to provide HTTP Authentication to Mesos. I would like to share the
design doc [1] in order to gather community feedback early enough
so we can address issues that might have scape us.

The design doc is still a work in progress, but we think it is mature
enough so that community could get involved.

Looking forward to your feedback!


[1]: 
https://docs.google.com/document/d/1kM3_f7DSqXcE2MuERrLTGp_XMC6ss2wmpkNYDCY5rOM 
https://docs.google.com/document/d/1kM3_f7DSqXcE2MuERrLTGp_XMC6ss2wmpkNYDCY5rOM

Re: Mesos Style Guideline Adjustments

[Alexander Rojas]

I also vote up for that! I rather change our guidelines a little bit than 
waiting for months
to get our changes into the clang-format source without any security that it 
will actually land.

 On 31 Jul 2015, at 09:31, Alex Rukletsov a...@mesosphere.com wrote:
 
 I think automation is very important. If we should slightly change our
 style in order to set-up easily enforceable rules, I vote with both hands
 for that.
 
 On Fri, Jul 31, 2015 at 3:25 AM, Michael Park mcyp...@gmail.com wrote:
 
 Oops, sorry I was so excited that this could just solve the issue that I
 forgot to answer your question.
 
 In general, the clang-format strives to adopt widely used styles, which I'm
 not sure if we would be considered widely used. Aside from that, another
 concern was that it could take a while for our style proposals to make it
 upstream and for it to be useful.
 
 On Thu, Jul 30, 2015, 6:12 PM Michael Park mcyp...@gmail.com wrote:
 
 Is it worth adding our own style?
 
 
 
 I noticed other have (LLVM, Google, Chromium, Mozilla, WebKit.). How
 hard is it?
 
 
 I was just looking into this again and *Mozilla* was added as the newest
 *BreakBeforeBraces* style. It breaks before braces on enum, function, and
 record definitions (struct, class, union). I think we can actually use
 that
 one and be done with it. Having looked through the codebase, we wrap the
 braces for *enum* for about half of the cases. It would be about 35
 instances that we have to fix from what I can see in our codebase. What
 do
 you think?
 
 On Thu, Jul 30, 2015 at 5:14 PM Benjamin Mahler 
 benjamin.mah...@gmail.com
 wrote:
 
 Is it worth adding our own style?
 
 I noticed other have (LLVM, Google, Chromium, Mozilla, WebKit.). How
 hard
 is it?
 
 On Thu, Jul 30, 2015 at 4:23 PM, Michael Park mcyp...@gmail.com
 wrote:
 
 There are a few syntactical Mesos style guidelines that I would like
 to
 propose to drop. They are:
 
   1. Open braces for namespace should not be wrapped.
   *NOTE*: The Google style guide does not wrap the brace after
 *namespace*,
   and the Mesos style guide does not mention a rule at all. But it is
   consistent throughout the codebase.
   2. Overloaded operators should be padded with spaces.
   3. Comments should be wrapped at 70 characters.
 
 The main motivation is that as a community we would like to reduce the
 discrepancy between what *clang-format* produces. This is a dual
 effort, as
 we work on improving *clang-format* to support some of our style which
 is
 popular in the C++ community as well. Wrapping the function arguments
 to
 avoid jaggedness for example is a feature request which is being
 tracked
 at: https://llvm.org/bugs/show_bug.cgi?id=23422
 
 Going forward, the proposal is to update all of the instances of (1)
 and
 (2) at once. For (3), we can simply relax the constraint from 70 to 80
 without touching the existing comments.
 
 Does anyone have any strong opinions about dropping any of the 3 rules
 above?
 
 Thanks,
 
 MPark.
 
 
 
 

[proposal] Generalized Authorizer Interface

[Alexander Rojas]

Hi everyone,

The current mesos::Authorizer API has one method for each of the actions 
supported (Register Framework, Launch Task and Shutdown Framework), and each of 
these actions define the objects on which they operate.

Currently, if the Authorizer needs to be extended by adding a new action, it is 
necessary to modify the mesos::Authorizer interface and all its implementations 
(currently only mesos::LocalAuthorizer), and add a new nested message to the 
ACL 
message in mesos.proto.

I want to propose a new version of the mesos::Authorizer interface which allows
implementations to offer any set of custom actions. It also hides implementation
details of how authorization is performed with the goal to allow for different
authorization backends.

The updated interface will look then like this:

class Authorizer {
public:
  virtual ~Authorizer() {}

  virtual process::Futurebool authorize(
  const OptionPrincipal principal,
  const Action action,
  const OptionObject object) = 0;

protected:
  Authorizer() {}
};

Where Principal, Action and Object are protocol buffer generated objects defined
as:

message Principal {
  required string value = 1;
  repeated Parameter attributes = 2;
}

message Action {
  required string value = 1;
  repeated Parameter attributes = 2;
}

message Object {
  required string value = 1;
  repeated Parameter attributes = 2;
}

The full text of the proposal can be found at
https://docs.google.com/document/d/1-XARWJFUq0r_TgRHz_472NvLZNjbqE4G8c2JL44OSMQ/edit

Note that Mesos users which defined ACLs through the --acls flags should not
notice any change in behavior after the change.

We’d love to get people’s feedback so we can move forward!

Thanks,
Alexander Rojas

Style guide for std::move

[Alexander Rojas]

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

[Alexander Rojas]

Hey Marco,

Thanks for doing this!

+1 removing “closed”
+1 to go back from “Reviewable” to “In Progress”
+1 to go from “In Progress” to “Accepted” instead of “Open”
+1 Removing “Reopened


 On 09 Jun 2015, at 23:26, Marco Massenzio 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: On Locales

[Alexander Rojas]

You’re right, I will mark the issue with a TODO and add a Jira ticket.


 On 20 May 2015, at 18:41, Vetoshkin Nikita nikita.vetosh...@gmail.com wrote:
 
 I think situation with locales is similar one to SIGPIPE issues we had a
 while ago, i.e as long as libprocess and stout are considered being
 libraries we can't force users to set process global flags like SIG_IGN.
 So I guess we should fix (or at least mark as FIXME) all locale related
 cases like we did with SIGPIPE.
 
 On Wed, May 20, 2015, 10:31 Alexander Rojas alexan...@mesosphere.io wrote:
 
 Hey guys, I just got a review pointing out that ‘strftime’ is dependent on
 the locale used. This not only affects my patch but code already in Mesos:
 process/time.hpp and encoder.hpp both make use of fields which are locale
 specific. The question here is, how to deal with it?
 
 Locales tend to be a pain since the functions handling them are not thread
 safe, so I would suggest setting a global locale for mesos programs (master
 and slaves) on start up, i.e. setlocale(LC_ALL, C);

On Locales

[Alexander Rojas]

Hey guys, I just got a review pointing out that ‘strftime’ is dependent on the 
locale used. This not only affects my patch but code already in Mesos: 
process/time.hpp and encoder.hpp both make use of fields which are locale 
specific. The question here is, how to deal with it?

Locales tend to be a pain since the functions handling them are not thread 
safe, so I would suggest setting a global locale for mesos programs (master and 
slaves) on start up, i.e. setlocale(LC_ALL, C);

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

[Alexander Rojas]

+1 non binding (Tested in OSX and 3 VM’s cluster running Ubuntu 12.10)

 On 30 Apr 2015, at 00:48, Adam Bordelon a...@mesosphere.io wrote:
 
 Hi all,
 
 Please vote on releasing the following candidate as Apache Mesos 0.22.1.
 
 0.22.1 is a bug fix release and includes the following:
 
  * [MESOS-1795] - Assertion failure in state abstraction crashes JVM.
  * [MESOS-2161] - AbstractState JNI check fails for Marathon framework.
  * [MESOS-2461] - Slave should provide details on processes running in its
 cgroups
  * [MESOS-2583] - Tasks getting stuck in staging.
  * [MESOS-2592] - The sandbox directory is not chown'ed if the fetcher
 doesn't run.
  * [MESOS-2601] - Tasks are not removed after recovery from slave and
 mesos containerizer
  * [MESOS-2614] - Update name, hostname, failover_timeout, and webui_url
 in master on framework re-registration
  * [MESOS-2643] - Python scheduler driver disables implicit
 acknowledgments by default.
  * [MESOS-2668] - Slave fails to recover when there are still processes
 left in its cgroup
 
 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.1-rc6
 
 
 The candidate for Mesos 0.22.1 release is available at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.1-rc6/mesos-0.22.1.tar.gz
 
 The tag to be voted on is 0.22.1-rc6:
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.22.1-rc6
 
 The MD5 checksum of the tarball can be found at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.1-rc6/mesos-0.22.1.tar.gz.md5
 
 The signature of the tarball can be found at:
 https://dist.apache.org/repos/dist/dev/mesos/0.22.1-rc6/mesos-0.22.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-1054
 
 Please vote on releasing this package as Apache Mesos 0.22.1!
 
 The vote is open until Mon May 4 18:00:00 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.1
 [ ] -1 Do not release this package because ...
 
 Thanks,
 -Adam-

Re: Using boost filesystem

[Alexander Rojas]

I do agree having this discussion. While I wouldn’t be for using every single 
boost library (spirit comes to mind as one we should avoid), using libraries 
like filesystem, thread or smart printers would reduce the amount of code we 
should maintain, while being certain we are using high quality libraries which 
are widely tested and maintained.


 On 22 Apr 2015, at 20:36, Cody Maloney c...@mesosphere.io wrote:
 
 It's not header only.
 
 I think we actually need a general discussion around upgrading all the
 libraries mesos depends upon (Using a plain up-stream boost, etc).
 
 Note that some portions of stout already require callers to link against
 specific libraries for them to actually work, so I don't think the
 header-only is that big of a requirement. But definitely we should have a
 discussion around it.
 
 On Wed, Apr 22, 2015 at 9:34 AM, Vinod Kone vinodk...@gmail.com wrote:
 
 Is it header only?
 
 On Wed, Apr 22, 2015 at 2:31 AM, Alexander Rojas alexan...@mesosphere.io
 wrote:
 
 Hey guys,
 
 I was checking one of my reviews which call for using some unimplemented
 functionality in stout path. Since that class has no methods, attributes
 or
 anything apart from a string value attribute; I was left wondering,
 wether
 it makes sense to use boost filesystem.
 
 Boost filesystem v3 has all the functionality we may need from a path
 class, it is the basis fro a technical recommendation (
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf 
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf) and
 might become part of the standard in the future. Why not adopt it in
 mesos?
 
 Alexander
 

Re: Review Request 33295: Added firewall mechanism to control access on libprocess http endpoints.

[Alexander Rojas]

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

(Updated April 22, 2015, 4:35 p.m.)


Review request for mesos, Adam B, Benjamin Hindman, and Till Toenshoff.


Changes
---

Changes the license header on new file for the correct one.
Changes name on implemented firewall rule to DisabledEndpointsRule.


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


Repository: mesos


Description
---

Introduces the interface `FirewallRule` which will be matched against incoming 
connections in order to allow them to be served or being blocked. For details, 
check the [design 
doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).


Diffs (updated)
-

  3rdparty/libprocess/include/Makefile.am 
3da3e6cef1b5cb66c223425744d84741846ea730 
  3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION 
  3rdparty/libprocess/include/process/process.hpp 
392c74df3e8a122aecd3633dffdeec4bcbd1f097 
  3rdparty/libprocess/src/process.cpp 97ac09fd10b767bc46387abc3657d005a00830c8 
  3rdparty/libprocess/src/tests/process_tests.cpp 
eb38edce2c483ba7f963a826893a15a075238618 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: statusUpdate always RUNNING even after job has finished

[Alexander Rojas]

Hey Zack,

Which value are you for the setting implicitAknowledge parameter in the 
SchedulerDriver constructor? if it is set to false, you will have to manually 
knowledge every statusUpdate, otherwise the executor will try to retry.

Are you using the python bindings? It seems that the default value there is set 
to false.

Alexander


 On 20 Apr 2015, at 16:25, Zack Booth Simpson zack.simp...@gmail.com wrote:
 
 I'm building a simple framework as a proof of concept. I launchTasks()
 successfully and my job (which is nothing but a sleep and an echo) runs
 fine. I can see its output in the trace files. Mesos UI says FINSIHED but
 statusUpdate keeps returning RUNNING to me over and over again.
 
 Any ideas?
 
 Zack

Re: Review Request 33358: Moved implementation of StatusUpdateStream to a compilation unit.

[Alexander Rojas]

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

(Updated April 22, 2015, 11:09 a.m.)


Review request for mesos, Alexander Rukletsov, Joerg Schad, and Till Toenshoff.


Changes
---

Adresses Alex's comments.


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


Repository: mesos


Description
---

Moves the implementation of StatusUpdateStream to a compilation unit.
Also cleans up headers.


Diffs (updated)
-

  src/slave/status_update_manager.hpp b4d91b22b515195fdb69c89af9c2864e469e7e54 
  src/slave/status_update_manager.cpp fab8c22d46b8ab0a3c3745541ddc650b574bfbd4 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 32163: Added a function which checks if a json object is contained within another.

[Alexander Rojas]

 On April 21, 2015, 1:50 a.m., Marco Massenzio wrote:
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp, line 315
  https://reviews.apache.org/r/32163/diff/8/?file=935461#file935461line315
 
  while I appreciate being thorough, strictly speaking this should not be 
  here: you're actually unittesting `JSON::parse()` with this `CHECK`
  
  two downsides:
  
  1. your test code is more verbose (and less readable);
  2. you may have failures here that are entirely unrelated to `Contains` 
  (causing folks to go scratching their head)
   
  Also, I would add some variety to your tests:
  ```
  {an_array_of_doubles: [1.0, -22.33, 99.876]}
  {an_array_of_arrays: [[2, 3], [99, -1]]}
  {an_array_of_objects:[{foo: 1, bar: 2, values: [5, 8, -1]}
  ```

The array of objects existed before, but it is after the objects tests.


- Alexander


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


On April 20, 2015, 6:28 p.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32163/
 ---
 
 (Updated April 20, 2015, 6:28 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Marco Massenzio, Niklas Nielsen, and Till Toenshoff.
 
 
 Bugs: MESOS-2510
 https://issues.apache.org/jira/browse/MESOS-2510
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Adds a function which allows to perform comparison tests on subsets of json 
 blobs. i.e.
 
 ```cpp
 JSON::Value expected = JSON::parse(
 {
   \key\ : true
   }).get();
 
 // Returned json:
 // {
 //   uptime : 45234.123,
 //   key : true
 // }
 JSON::Value actual = bar();
 
 // I'm only interested on the key entry and ignore the rest.
 EXPECT_TRUE(contains(actual, expected));
 ```
 
 Increasing readability for tests that include json.
 
 For more information on the reason of why this patch is needed, please check 
 the JIRA entry.
 
 
 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/32163/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

Re: Review Request 33296: Added a flag which controls libprocess firewall initialzation.

[Alexander Rojas]

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

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


Review request for mesos, Adam B, Benjamin Hindman, and Till Toenshoff.


Changes
---

making review public.


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


Repository: mesos


Description
---

See summary.


Diffs
-

  include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
  include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
  src/common/parse.hpp 547b32041f39f0ff0c38179b66a32b2239134abc 
  src/master/flags.hpp 996cf38c88f9718e55e88d6e906b5e3d1989478a 
  src/master/flags.cpp 5798989d3f135978ec3d5f714b1cd8d84180fc90 
  src/master/main.cpp 7cce3a0bb808a1cb7bac9acab31eb1c67a15ea9f 
  src/slave/flags.hpp d3b1ce117fbb4e0b97852ef150b63f35cc991032 
  src/slave/flags.cpp d0932b04e3825abb6173efe0d1aee199aa356932 
  src/slave/main.cpp c62d3ab9825bf952071e8e312d383a0cb46547d2 

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


Testing
---

make check and manual tests.


Thanks,

Alexander Rojas

Re: Review Request 33295: Added firewall mechanism to control access on libprocess http endpoints.

[Alexander Rojas]

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

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


Review request for mesos, Adam B, Benjamin Hindman, and Till Toenshoff.


Changes
---

making it public.


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


Repository: mesos


Description
---

Introduces the interface `FirewallRule` which will be matched against incoming 
connections in order to allow them to be served or being blocked. For details, 
check the [design 
doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).


Diffs
-

  3rdparty/libprocess/include/Makefile.am 
3da3e6cef1b5cb66c223425744d84741846ea730 
  3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION 
  3rdparty/libprocess/include/process/process.hpp 
392c74df3e8a122aecd3633dffdeec4bcbd1f097 
  3rdparty/libprocess/src/process.cpp 97ac09fd10b767bc46387abc3657d005a00830c8 
  3rdparty/libprocess/src/tests/process_tests.cpp 
eb38edce2c483ba7f963a826893a15a075238618 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 30612: Added /master/frameworks/{framework}/tasks/{task} endpoint.

[Alexander Rojas]

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

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


Review request for mesos, Ben Mahler, Marco Massenzio, Niklas Nielsen, and Till 
Toenshoff.


Changes
---

Adresses Marco's comments.


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


Repository: mesos


Description
---

Adds endpoints for paths /master/frameworks/{framework}/tasks/{task}.

Adds tests for the endpoints.

Works with [29883](https://reviews.apache.org/r/29883).

Builds on the abandoned patch 14286.


Diffs (updated)
-

  src/master/http.cpp 00c22c43bd1f6cef7963b2ffa9c095c6cbd01cd3 
  src/master/master.hpp c10e7c08c191acef9d31d98018a47a2a952a4dfc 
  src/master/master.cpp b1093bb867eb8624740f3d094cef2c23405a18b6 
  src/tests/master_tests.cpp 32b1e9bb58d8046e5363fafe2ab8f662b6c9a666 

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


Testing
---

make check


Thanks,

Alexander Rojas

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

[Alexander Rojas]

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

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


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, Marco 
Massenzio, Niklas Nielsen, and Till Toenshoff.


Changes
---

Updates confusing named variable `null` in the tests.


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 (updated)
-

  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 32163: Added a function which checks if a json object is contained within another.

[Alexander Rojas]

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

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


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, Marco 
Massenzio, Niklas Nielsen, and Till Toenshoff.


Changes
---

Addresses Marco's comments.


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


Repository: mesos


Description
---

Adds a function which allows to perform comparison tests on subsets of json 
blobs. i.e.

```cpp
JSON::Value expected = JSON::parse(
{
  \key\ : true
}).get();

// Returned json:
// {
//   uptime : 45234.123,
//   key : true
// }
JSON::Value actual = bar();

// I'm only interested on the key entry and ignore the rest.
EXPECT_TRUE(contains(actual, expected));
```

Increasing readability for tests that include json.

For more information on the reason of why this patch is needed, please check 
the JIRA entry.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
334c898906018be6e663f53815abbe047806b95c 
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 33358: Moved implementation of StatusUpdateStream to a compilation unit.

[Alexander Rojas]

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

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


Review request for mesos, Alexander Rukletsov, Joerg Schad, and Till Toenshoff.


Repository: mesos


Description
---

Moves the implementation of StatusUpdateStream to a compilation unit.
Also cleans up headers.


Diffs (updated)
-

  src/slave/status_update_manager.hpp b4d91b22b515195fdb69c89af9c2864e469e7e54 
  src/slave/status_update_manager.cpp fab8c22d46b8ab0a3c3745541ddc650b574bfbd4 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 33358: Moved implementation of StatusUpdateStream to a compilation unit.

[Alexander Rojas]

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

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


Review request for mesos, Alexander Rukletsov, Joerg Schad, and Till Toenshoff.


Changes
---

Adding JIRA Issue.


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


Repository: mesos


Description
---

Moves the implementation of StatusUpdateStream to a compilation unit.
Also cleans up headers.


Diffs
-

  src/slave/status_update_manager.hpp b4d91b22b515195fdb69c89af9c2864e469e7e54 
  src/slave/status_update_manager.cpp fab8c22d46b8ab0a3c3745541ddc650b574bfbd4 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 30612: Added /master/frameworks/{framework}/tasks/{task} endpoint.

[Alexander Rojas]

 On April 21, 2015, 2:51 a.m., Marco Massenzio wrote:
  src/master/http.cpp, line 298
  https://reviews.apache.org/r/30612/diff/12/?file=935462#file935462line298
 
  argubaly this should be DEBUG (but don't really feel strongly about 
  this)

Agree with you, but every other request uses `LOG(INFO)` and mesos as a general 
rule goes for consitency.


 On April 21, 2015, 2:51 a.m., Marco Massenzio wrote:
  src/master/http.cpp, line 300
  https://reviews.apache.org/r/30612/diff/12/?file=935462#file935462line300
 
  can we have all routes patters as CONSTANTS defined in the class 
  header? definitely easier to debug etc.
 
 Alexander Rukletsov wrote:
 Marco, we tend not to use constants for non-POD types: 
 https://issues.apache.org/jira/browse/MESOS-1023
 An example of a prefered way is `MAX_REAP_INTERVAL()` from `reap.hpp`. 
 
 In this particular case, why do you want to increase the visibility scope 
 of this constant?

I don't think this pattern should be move out of the function. There are 
multiple reasons for this:

1. The variable `pattern` is not used outside the scope of this method, so 
there's no need to take it outside.
2. `pattern` doesn't represent the path of the handler, since it is redirected 
from `/master/frameworks`.
3. We avoid having static class objects (though it could be converted to a 
`const char*`).
4. How is it easier to debug? I would probably have to go to another file if I 
want to check the contents of `pattern` as opposed from looking in the local 
function itself.
5. You can check the first niq's review on 
[29883](https://reviews.apache.org/r/29883/) as to why it is not capitalized.


- Alexander


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


On April 20, 2015, 6:27 p.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/30612/
 ---
 
 (Updated April 20, 2015, 6:27 p.m.)
 
 
 Review request for mesos, Ben Mahler, Marco Massenzio, Niklas Nielsen, and 
 Till Toenshoff.
 
 
 Bugs: MESOS-2157
 https://issues.apache.org/jira/browse/MESOS-2157
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Adds endpoints for paths /master/frameworks/{framework}/tasks/{task}.
 
 Adds tests for the endpoints.
 
 Works with [29883](https://reviews.apache.org/r/29883).
 
 Builds on the abandoned patch 14286.
 
 
 Diffs
 -
 
   src/master/http.cpp 00c22c43bd1f6cef7963b2ffa9c095c6cbd01cd3 
   src/master/master.hpp c10e7c08c191acef9d31d98018a47a2a952a4dfc 
   src/master/master.cpp e30b951eda2b3b0d5b2a80716f0b32c6bbe041bc 
   src/tests/master_tests.cpp 32b1e9bb58d8046e5363fafe2ab8f662b6c9a666 
 
 Diff: https://reviews.apache.org/r/30612/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Alexander Rojas
 

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

[Alexander Rojas]

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

(Updated April 20, 2015, 1:58 p.m.)


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
Michael Park, and Till Toenshoff.


Changes
---

Fixes wrong namespace after rebase.


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 (updated)
-

  3rdparty/libprocess/include/process/http.hpp 
07825b2b7195fe7fe752e8fda65b7f0a8b8b1f38 
  3rdparty/libprocess/src/process.cpp 97ac09fd10b767bc46387abc3657d005a00830c8 
  3rdparty/libprocess/src/tests/process_tests.cpp 
eb38edce2c483ba7f963a826893a15a075238618 

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


Testing
---

make check


Thanks,

Alexander Rojas

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

[Alexander Rojas]

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

Ship it!


Ship It!

- Alexander Rojas


On April 18, 2015, 3:34 a.m., Till Toenshoff wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/1/
 ---
 
 (Updated April 18, 2015, 3: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 30032: Added support for cache control in libprocess when dealing with static files.

[Alexander Rojas]

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

(Updated April 20, 2015, 1:19 p.m.)


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
Michael Park, and Till Toenshoff.


Changes
---

Update to take into account some of the comments.


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 (updated)
-

  3rdparty/libprocess/include/process/http.hpp 
07825b2b7195fe7fe752e8fda65b7f0a8b8b1f38 
  3rdparty/libprocess/src/process.cpp 97ac09fd10b767bc46387abc3657d005a00830c8 
  3rdparty/libprocess/src/tests/process_tests.cpp 
eb38edce2c483ba7f963a826893a15a075238618 

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


Testing
---

make check


Thanks,

Alexander Rojas

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

[Alexander Rojas]

 On March 26, 2015, 5: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.
 
 Till Toenshoff wrote:
 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?
 
 Alexander Rukletsov wrote:
 C++11 Standard 17.6.1.2 p4, p8, and reference 177 hint at a preferred 
 form for C++ programs.
 
 Alexander Rojas wrote:
 I think the best would be to add a discussion on the dev list, since 
 changing to the `cname` version would require to prefix every call with the 
 prefix `std::`
 
 Alexander Rojas wrote:
 Preferred is a very different thing from required, as mention originally. 
 And I do agree that I prefer in my private projects to use the `cname` 
 versions. However, I wouldn't do that since it has the capacity of becoming 
 red herring.

Droping because the discusion when nowhere, so we keep the status quo.


- Alexander


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


On March 26, 2015, 10: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, 10: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 32198: Added a not equal operator for json objects.

[Alexander Rojas]

 On April 20, 2015, 5:18 p.m., Niklas Nielsen wrote:
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp, line 258
  https://reviews.apache.org/r/32198/diff/3/?file=903041#file903041line258
 
  How about also checking for a larger array?

What can be considered larger? 5 elements, 10 elements, 100 elements? I 
personally don't think it makes any difference for the equality operator, since 
the comparison is still linear.


- Alexander


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


On April 20, 2015, 5:19 p.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/32198/
 ---
 
 (Updated April 20, 2015, 5:19 p.m.)
 
 
 Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, 
 Marco Massenzio, 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 32163: Added a function which checks if a json object is contained within another.

[Alexander Rojas]

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

(Updated April 20, 2015, 6:28 p.m.)


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, Marco 
Massenzio, Niklas Nielsen, and Till Toenshoff.


Changes
---

Rebased


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


Repository: mesos


Description
---

Adds a function which allows to perform comparison tests on subsets of json 
blobs. i.e.

```cpp
JSON::Value expected = JSON::parse(
{
  \key\ : true
}).get();

// Returned json:
// {
//   uptime : 45234.123,
//   key : true
// }
JSON::Value actual = bar();

// I'm only interested on the key entry and ignore the rest.
EXPECT_TRUE(contains(actual, expected));
```

Increasing readability for tests that include json.

For more information on the reason of why this patch is needed, please check 
the JIRA entry.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
334c898906018be6e663f53815abbe047806b95c 
  3rdparty/libprocess/3rdparty/stout/tests/json_tests.cpp 
f60d1bbe60f2e2b6460c06bba98e8b85ebb6a3f9 

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


Testing
---

make check


Thanks,

Alexander Rojas

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

[Alexander Rojas]

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

(Updated April 20, 2015, 6:28 p.m.)


Review request for mesos, Benjamin Hindman, Bernd Mathiske, Joerg Schad, Marco 
Massenzio, Niklas Nielsen, and Till Toenshoff.


Changes
---

Rebased


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 (updated)
-

  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 30612: Added /master/frameworks/{framework}/tasks/{task} endpoint.

[Alexander Rojas]

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

(Updated April 20, 2015, 6:27 p.m.)


Review request for mesos, Ben Mahler, Marco Massenzio, Niklas Nielsen, and Till 
Toenshoff.


Changes
---

Rebased


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


Repository: mesos


Description
---

Adds endpoints for paths /master/frameworks/{framework}/tasks/{task}.

Adds tests for the endpoints.

Works with [29883](https://reviews.apache.org/r/29883).

Builds on the abandoned patch 14286.


Diffs (updated)
-

  src/master/http.cpp 00c22c43bd1f6cef7963b2ffa9c095c6cbd01cd3 
  src/master/master.hpp c10e7c08c191acef9d31d98018a47a2a952a4dfc 
  src/master/master.cpp e30b951eda2b3b0d5b2a80716f0b32c6bbe041bc 
  src/tests/master_tests.cpp 32b1e9bb58d8046e5363fafe2ab8f662b6c9a666 

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


Testing
---

make check


Thanks,

Alexander Rojas

Re: Review Request 33154: Added reason metrics for slave removals.

[Alexander Rojas]

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



src/master/master.hpp
https://reviews.apache.org/r/33154/#comment130360

I find this quite counter intuitive for two reasons:
1. If I just check this header, I would expect reason to behave a little 
like an enum, telling me why the slave is being removed. What i didn't expect, 
is that it is a counter to the number of slaves being removed by `reason`.
2. The parameter is a const ref, last thing I expected is that it would 
change later on.

Can you add a comment explaining the semantics of reason, and if possible, 
getting rid of the const ref?


- Alexander Rojas


On April 14, 2015, 3:46 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33154/
 ---
 
 (Updated April 14, 2015, 3:46 a.m.)
 
 
 Review request for mesos and Vinod Kone.
 
 
 Bugs: MESOS-2485
 https://issues.apache.org/jira/browse/MESOS-2485
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See [MESOS-2485](https://issues.apache.org/jira/browse/MESOS-2485).
 
 
 Diffs
 -
 
   include/mesos/mesos.proto 3a8e8bf303e0576c212951f6028af77e54d93537 
   src/master/master.hpp 6141917644b84edfed9836fa0a005d55a36880e3 
   src/master/master.cpp 44b0a0147f5354824d86332a67b30018634c9a36 
   src/master/metrics.hpp 52a83289cfe7e6b6fd8d5bff0774ebe5ce51d0ed 
   src/master/metrics.cpp 14486bf7130250f561c9fb7a43c95f3fc1e76a4b 
 
 Diff: https://reviews.apache.org/r/33154/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Ben Mahler
 

Re: Review Request 33155: Added commented-out tests for slave removal metrics.

[Alexander Rojas]

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



src/tests/master_tests.cpp
https://reviews.apache.org/r/33155/#comment130363

+1


- Alexander Rojas


On April 14, 2015, 3:46 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33155/
 ---
 
 (Updated April 14, 2015, 3:46 a.m.)
 
 
 Review request for mesos and Vinod Kone.
 
 
 Bugs: MESOS-2485
 https://issues.apache.org/jira/browse/MESOS-2485
 
 
 Repository: mesos
 
 
 Description
 ---
 
 I updated the existing tests to validate the metrics. However, it blocks the 
 tests due to the slave metrics never getting satisfied. Added a TODO.
 
 
 Diffs
 -
 
   src/tests/master_tests.cpp 32b1e9bb58d8046e5363fafe2ab8f662b6c9a666 
   src/tests/partition_tests.cpp 1018e479a77a6b533f2dd392fedbdccb80e3ac1f 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33155/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Ben Mahler
 

Re: Review Request 33263: Extended SlaveTest.ShutdownUnregisteredExecutor test with a reason check.

[Alexander Rojas]

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

Ship it!


Ship It!

- Alexander Rojas


On April 16, 2015, 4:31 p.m., Andrey Dyatlov wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33263/
 ---
 
 (Updated April 16, 2015, 4:31 p.m.)
 
 
 Review request for mesos, Alexander Rukletsov, Bernd Mathiske, and Till 
 Toenshoff.
 
 
 Bugs: MESOS-2625
 https://issues.apache.org/jira/browse/MESOS-2625
 
 
 Repository: mesos
 
 
 Description
 ---
 
 Extended SlaveTest.ShutdownUnregisteredExecutor test with a reason check. 
 Check that the reason is REASON_COMMAND_EXECUTOR_FAILED. According to the 
 Slave::sendExecutorTerminatedStatusUpdate member function, this reason is 
 expected instead of more general REASON_EXECUTOR_TERMINATED because the 
 command executer is used in this test.
 
 
 Diffs
 -
 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33263/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Andrey Dyatlov
 

Re: Review Request 33152: Moved the slave shutdown test into slave_tests.cpp.

[Alexander Rojas]

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

Ship it!


Can you please add the JIRA number in the review?


src/tests/slave_tests.cpp
https://reviews.apache.org/r/33152/#comment130359

One line break too many.


- Alexander Rojas


On April 14, 2015, 3:46 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33152/
 ---
 
 (Updated April 14, 2015, 3:46 a.m.)
 
 
 Review request for mesos and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   src/tests/fault_tolerance_tests.cpp 
 a637c32f004638a110390b22cf5b626e904097cf 
   src/tests/slave_tests.cpp b826000e0a4221690f956ea51f49ad4c99d5e188 
 
 Diff: https://reviews.apache.org/r/33152/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Ben Mahler
 

Re: Review Request 33153: Moved a partition test into partition_tests.cpp.

[Alexander Rojas]

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

Ship it!


As in the previous case, can you add the JIRA issue link. I also would like to 
understand why the move is needed (though I might see it later).

- Alexander Rojas


On April 14, 2015, 3:46 a.m., Ben Mahler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/33153/
 ---
 
 (Updated April 14, 2015, 3:46 a.m.)
 
 
 Review request for mesos and Vinod Kone.
 
 
 Repository: mesos
 
 
 Description
 ---
 
 See summary.
 
 
 Diffs
 -
 
   src/tests/fault_tolerance_tests.cpp 
 a637c32f004638a110390b22cf5b626e904097cf 
   src/tests/partition_tests.cpp 1018e479a77a6b533f2dd392fedbdccb80e3ac1f 
 
 Diff: https://reviews.apache.org/r/33153/diff/
 
 
 Testing
 ---
 
 make check
 
 
 Thanks,
 
 Ben Mahler
 

Re: Review Request 31985: Mesos container ID available to the executor through an environment variable.

[Alexander Rojas]

 On March 14, 2015, 1:49 a.m., Timothy Chen wrote:
  The change looks good, but I'm not sure how exposing the container id is 
  the right thing to do overall yet. Container id as I know of is meant to be 
  a internal id that is used only in mesos, and I believe the whole 
  motivation was for users to be able to guess the docker container name from 
  the container id. However, container id - docker container name mapping 
  might change since we manage that, and I'm progress changing it to include 
  the slave id.
  
  I personally think we should think about exposing container specific 
  information.
  
  Do you know if there is any other use case to know the container id?
 
 Alexander Rojas wrote:
 1. I am not aware of any other use case. However I asked benh about this 
 and he mentioned it was ok to have this as extra info on the update, as long 
 as it was no docker specific data.
 2. After asking some questions to the original reporter, the idea was 
 more to be able to group tasks assigned to the same container, but not as a 
 way to extract the specific container.
 3. I am not sure, then, what would be considered mesos private info and 
 info which can be shared. For example, why can the framework id and the 
 executor id be shared but no the container id?
 
 Vinod Kone wrote:
 group tasks assigned to the same container  .. What does this mean? 
 IIUC, our docker containerizer only supports single task containers.
 
 regarding why framework id and executor id are exposed: framework id is 
 needed by frameworks to reregister with master. executor id (and task id) is 
 generated by the framework and not mesos.
 
 Alexander Rojas wrote:
 So I guess then, I will discard this patch and set the issue to won't fix?
 
 Vinod Kone wrote:
 I think we should try to understand the root of the issue that the 
 reporter is having before jumping onto a specific implementation.
 
 Alexander Rojas wrote:
 Well, I felt like I had it clear but apparently not. Can you please ask 
 the questions in the Jira entry vinod?
 
 I was also wondering, As mentioned above, we want to keep the 
 `containerId` private within mesos, but patch 
 [32426](https://reviews.apache.org/r/32426) effectively makes it public.
 
 Alexander Rojas wrote:
 I got it now… it is still quite private. Forget my question on the second 
 paragraph.
 
 Alexander Rojas wrote:
 One more thing Vinod, you wrote one container per task, however if you 
 check the code (Slave.cpp at `Executor* 
 Framework::launchExecutor(ExecutorInfo, TaskInfo)`) what we have is one 
 container per executor.
 
 Timothy Chen wrote:
 Docker containerizer supports multiple tasks only if the container is a 
 custom executor, so you get grouping naturally through that. 
 From what I understand most people wants the container ID so they can get 
 docker specific information like name, IP, etc. I think by sending this all 
 back through the docker executor we shouldn't need this anymore.

Hey guys, I asked the reporter of the issue the reason why he needs it. He 
wrote a full explanation on the [JIRA 
Issue](https://issues.apache.org/jira/browse/MESOS-2191?focusedCommentId=14387724page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14387724),
 so if you can read that and then decide if it is worth commiting this patch or 
not.


- Alexander


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


On March 20, 2015, 10:27 a.m., Alexander Rojas wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/31985/
 ---
 
 (Updated March 20, 2015, 10:27 a.m.)
 
 
 Review request for mesos, Bernd Mathiske, Isabel Jimenez, Joerg Schad, Till 
 Toenshoff, and Vinod Kone.
 
 
 Bugs: MESOS-2191
 https://issues.apache.org/jira/browse/MESOS-2191
 
 
 Repository: mesos
 
 
 Description
 ---
 
 When the executor is created, the container ID where it runs is made 
 accesible through an environment variable.
 
 
 Diffs
 -
 
   src/exec/exec.cpp d678f0682d803b0b080c3a6c296067ac9ab5dbf8 
   src/slave/containerizer/containerizer.hpp 
 129e60f20835f5d151701e934330b81825887af1 
   src/slave/containerizer/containerizer.cpp 
 4d66e767de1f877cb66b37826ba7c9d00639a7c0 
   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
   src/slave/containerizer/docker.cpp 5f4b4ce49a9523e4743e5c79da4050e6f9e29ed7 
   src/slave/containerizer/external_containerizer.cpp 
 42c67f548caf7bddbe131e0dfa7d74227d8c2593 
   src/slave/containerizer/mesos/containerizer.cpp 
 fbd1c0a0e5f4f227adb022f0baaa6d2c7e3ad748 
   src/tests/containerizer.cpp

Re: Inlined code

[Alexander Rojas]

+1 I will try to do so when I have free cycles.

 On 10 Apr 2015, at 20:22, Benjamin Mahler benjamin.mah...@gmail.com wrote:
 
 Let's also try to measure the impact on build time, going forward. Cody did
 a great job recently here:
 https://reviews.apache.org/r/32558/
 
 On Fri, Apr 10, 2015 at 8:01 AM, Alexander Rojas alexan...@mesosphere.io
 wrote:
 
 I agree with the fact that stout is headers only, but this is code in mess
 itself.
 
 
 On 10 Apr 2015, at 13:15, Alex Rukletsov a...@mesosphere.com wrote:
 
 wherever possible, but we are not going to m
 
 

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

[Alexander Rojas]

 On March 26, 2015, 5: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.
 
 Till Toenshoff wrote:
 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?
 
 Alexander Rukletsov wrote:
 C++11 Standard 17.6.1.2 p4, p8, and reference 177 hint at a preferred 
 form for C++ programs.

I think the best would be to add a discussion on the dev list, since changing 
to the `cname` version would require to prefix every call with the prefix 
`std::`


- Alexander


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


On March 26, 2015, 10: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, 10: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 31676: Added documentation about the use of the LIBPROCESS_DISABLED_ENDPOINTS environment variable.

[Alexander Rojas]

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

(Updated April 1, 2015, 11:47 a.m.)


Review request for mesos, Joerg Schad, Niklas Nielsen, and Till Toenshoff.


Changes
---

Endpoints disabling doesn't support wildcard matching anymore.


Bugs: mesos-2333
https://issues.apache.org/jira/browse/mesos-2333


Repository: mesos


Description
---

Adds documentation on how to disable endpoints using 
`LIBPROCESS_DISABLED_ENDPOINTS`.


Diffs (updated)
-

  docs/configuration.md 54c4e31ed6dfed3c23d492c19a301ce119a0519b 

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


Testing
---


Thanks,

Alexander Rojas

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

[Alexander Rojas]

 On March 26, 2015, 5: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.
 
 Till Toenshoff wrote:
 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?
 
 Alexander Rukletsov wrote:
 C++11 Standard 17.6.1.2 p4, p8, and reference 177 hint at a preferred 
 form for C++ programs.
 
 Alexander Rojas wrote:
 I think the best would be to add a discussion on the dev list, since 
 changing to the `cname` version would require to prefix every call with the 
 prefix `std::`

Preferred is a very different thing from required, as mention originally. And I 
do agree that I prefer in my private projects to use the `cname` versions. 
However, I wouldn't do that since it has the capacity of becoming red herring.


- Alexander


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


On March 26, 2015, 10: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, 10: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 31228: Added a mechanism for disabling http endpoints.

[Alexander Rojas]

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

(Updated April 1, 2015, 11:50 a.m.)


Review request for mesos, Joerg Schad, Niklas Nielsen, and Till Toenshoff.


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


Repository: mesos


Description (updated)
---

Adds a mechanism for disabling http endpoints (e.g 
`testprocess/handler1,processname(3)/handler2`). A list of coma separated 
strings can be provided using the environment variable 
`LIBPROCESS_DISABLED_ENDPOINTS` which will be read during libprocess 
initialization. Then, when creating http endpoints (using the method `route`) 
the endpoint path will be checked against the patterns. If a match is found the 
endpoint handler will be replaced for a generic once which returns a 403 HTTP 
Error (Forbidden).


Diffs (updated)
-

  3rdparty/libprocess/include/process/process.hpp 
392c74df3e8a122aecd3633dffdeec4bcbd1f097 
  3rdparty/libprocess/src/process.cpp cf4e36489be2c6aa01e838c1c71383f248deab5b 
  3rdparty/libprocess/src/tests/process_tests.cpp 
eb38edce2c483ba7f963a826893a15a075238618 

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


Testing (updated)
---

make check


Thanks,

Alexander Rojas