March 15th, 2018 Mesos Developer Meeting

[Benjamin Hindman]

We'll have a developer meeting this Thursday at 3 PM PT. You'll find the
agenda here: https://docs.google.com/document/d/
153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit

If folks have anything they'd like to add to the agenda please add it and
ping Jie (cc'ed) who will run this week's meeting.

You can join the meeting via Zoom by clicking here: https://zoom.us/j/
885219228

Looking forward!

MesosCon 2018

[Benjamin Hindman]

Fellow Mesos Community Members,

Many of you have probably seen the announcement for Mesosphere Advance, a
conference co-located at CloudNativeCon. Given the deep involvement that
Mesosphere has had with past MesosCons, this has left many of you asking us
if Mesosphere Advance replaces MesosCon.

No, it does not. Mesosphere Advance is the evolution of DC/OS Day which was
previously co-located with MesosCon and is focused on DC/OS and its
ecosystem. Having said that, Mesos is a big part of the DC/OS ecosystem and
we’ll be featuring Mesos and Mesos related projects prominently at
Mesosphere Advance. We’d love for you and your teams to consider submitting
talk there! Check out
https://www.surveymonkey.com/r/europe18-mesosphereadvance for more info.

So, where does that leave MesosCon? In the past Mesosphere has almost
exclusively managed the organization of MesosCon and going forward we want
it to be more community organized. To that end, we–a group of Mesos users
and developers (including Mesosphere)–are currently in the process of
organizing a MesosCon event and we should have an update soon, so please
stay tuned.

If you have questions, suggestions, or want to get involved in the planning
process, feel free to reach out to us personally!

Ben (PMC Chair) & Joerg (MesosCon Chair)

Reminder: Share your thoughts in our Apache Mesos Survey

[Benjamin Hindman]

We're close to shipping the next Mesos release (1.5.0) and after a great
set of MesosCons in Beijing, LA, and Prague in 2017 we're also starting to
think about 2018 conferences. It's exciting!


One of the ways we help improve the project is with input from folks in our
user and developer communities. Your feedback is critical to help us think
about what we should focus on in the next year. To facilitate this Mesosphere
is running a short survey to understand the usage of Apache Mesos, the
needs of users, and how to improve it going forward.

The aggregate statistics will be publicly shared but all of your responses
will remain confidential. In appreciation for your participation you will
be entered to win your choice of a DJI Spark Drone or an Apple Watch 3!



Thank you in advance for
participating!

Ben

2018/01/18 Mesos Developer Meeting

[Benjamin Hindman]

We'll have a developer meeting tomorrow at 3 PM PT. You'll find the agenda
here:
https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit

Some highlights from the agenda are discussions about 1.5.0 features and
some recent performance improvements!

You can join the meeting via Zoom by clicking here:
https://zoom.us/j/885219228

See you all then!

Re: ClangTidy for Mesos is here!

[Benjamin Hindman]

MPark, this is so awesome to see; everyone in the community is indebted to
you for continuing to push on this! Thank you!!!


On Sat, Nov 4, 2017 at 3:18 PM Michael Park  wrote:

> We've had ClangTidy for Mesos, called MesosTidy for a while checked
> into the codebase, but we hadn't actually enabled it on the CI.
>
> I've created a Mesos-Tidybot job (to accompany Mesos-Buildbot) on
> our Apache CI, which will be reporting its status to the builds mailing
> list.
>
> The following is an example output from MesosTidy in its last run:
>
> /tmp/SRC/3rdparty/libprocess/src/http.cpp:675:10: warning: redundant call
> to 'data' [readability-redundant-string-cstr]
>   body = out.str().data();
>  ^
>  out.str()
>
> This warning is generated from a built-in ClangTidy check called
> readability-redundant-string-cstr
> <
> http://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-string-cstr.html
> >,
> which checks for unnecessary
> calls to `std::string::c_str` and `std::string::data`.
>
> Not a critical issue for us by any measure, but it's very important to
> note that this is a __semantic__ check and I hope it gives you
> a sense of the type of checks that ClangTidy is capable of.
>
> Another thing to note is that it even suggests a fix!
> Namely, to change `out.str().data()` to `out.str()`.
> I've put up a review to make this change here: r63560
> 
>
> Today, we start with a very small number of checks:
>
>- `mesos-flags-inheritance`
>   - Ensures that Flags always inherits virtually for composability.
>- `mesos-namespace-comments`
>   - Ensures that namespaces end with `// namespace foo {`
>- `readability-redundant-string-cstr`
>   - As we saw above.
>
> We also have a `mesos-this-capture` check which will tell you when
> you've captured the `this` pointer of a class in a libprocess continuation
> but without a `defer` to `self`. This is disabled today however, since
> there
> are few false positives related to the uses of `process::loop`. I really
> hope
> to get around to updating the check and enable it soon!
>
> There are also a slew of checks that ship with ClangTidy that we'll be
> enabling as well. http://clang.llvm.org/extra/clang-tidy/checks/list.html
> Notably a lot of the `google-*` checks are relevant for us.
>
> You can also run `mesos-tidy` locally on your machine by running
> `./support/mesos-tidy.sh`.
>
> Let's say this is an alpha launch. There are lots of things missing,
> and things aren't going to be perfect, but I think that the framework
> that is there today is a good start for us. We'll certainly be changing
> things and improving as we go.
>
> Thank you to Benjamin Bannier for helping out with so much of this work.
> He's been a really big help and an advocate for additional tools.
>
> Thanks,
>
> MPark
>

Re: organizing a "docathon"

[Benjamin Hindman]

Please see this doc
<https://docs.google.com/document/d/1-biNAKITW5mFpYlAE0gH-ycReTHVOv7pak_NTNL17x4/edit>
for more details as well as ideas for documentation. Please add more
yourself!


On Wed, Oct 4, 2017 at 6:19 PM Benjamin Hindman 
wrote:

> We've decided on Thursday 10/12!
>
> If you're interested in joining us in person in San Francisco please reply
> just to me.
>
> Stay tuned for more details. Looking forward!
>
> On Mon, Oct 2, 2017 at 6:05 PM Benjamin Hindman <
> benjamin.hind...@gmail.com> wrote:
>
>> Pinging this thread just to remind folks to sign up, thank you!
>>
>> On Mon, Sep 25, 2017 at 4:09 PM Benjamin Hindman <
>> benjamin.hind...@gmail.com> wrote:
>>
>>> Some folks have expressed interest in an organized documentation
>>> hackathon, aka "docathon".
>>>
>>> We'll make this something people can participate in remotely, but we'll
>>> also provide space (TBD, most likely at Mesosphere in San Francisco) for
>>> the first one of these for anyone that would like to join in person.
>>>
>>> Basic agenda will be for folks to get together to discuss where docs can
>>> be improved, then break into teams to work on improving the docs, then come
>>> back together for food/drinks and presentations on how we improved the docs
>>> along with some prizes!
>>>
>>> If you're interested in joining, please fill out this poll
>>> <https://doodle.com/poll/ui5da3g8c33z5dqn>.
>>>
>>> Looking forward to improving the docs with everyone!
>>>
>>

Re: organizing a "docathon"

[Benjamin Hindman]

We've decided on Thursday 10/12!

If you're interested in joining us in person in San Francisco please reply
just to me.

Stay tuned for more details. Looking forward!

On Mon, Oct 2, 2017 at 6:05 PM Benjamin Hindman 
wrote:

> Pinging this thread just to remind folks to sign up, thank you!
>
> On Mon, Sep 25, 2017 at 4:09 PM Benjamin Hindman <
> benjamin.hind...@gmail.com> wrote:
>
>> Some folks have expressed interest in an organized documentation
>> hackathon, aka "docathon".
>>
>> We'll make this something people can participate in remotely, but we'll
>> also provide space (TBD, most likely at Mesosphere in San Francisco) for
>> the first one of these for anyone that would like to join in person.
>>
>> Basic agenda will be for folks to get together to discuss where docs can
>> be improved, then break into teams to work on improving the docs, then come
>> back together for food/drinks and presentations on how we improved the docs
>> along with some prizes!
>>
>> If you're interested in joining, please fill out this poll
>> <https://doodle.com/poll/ui5da3g8c33z5dqn>.
>>
>> Looking forward to improving the docs with everyone!
>>
>

Re: organizing a "docathon"

[Benjamin Hindman]

Pinging this thread just to remind folks to sign up, thank you!

On Mon, Sep 25, 2017 at 4:09 PM Benjamin Hindman 
wrote:

> Some folks have expressed interest in an organized documentation
> hackathon, aka "docathon".
>
> We'll make this something people can participate in remotely, but we'll
> also provide space (TBD, most likely at Mesosphere in San Francisco) for
> the first one of these for anyone that would like to join in person.
>
> Basic agenda will be for folks to get together to discuss where docs can
> be improved, then break into teams to work on improving the docs, then come
> back together for food/drinks and presentations on how we improved the docs
> along with some prizes!
>
> If you're interested in joining, please fill out this poll
> <https://doodle.com/poll/ui5da3g8c33z5dqn>.
>
> Looking forward to improving the docs with everyone!
>

organizing a "docathon"

[Benjamin Hindman]

Some folks have expressed interest in an organized documentation hackathon,
aka "docathon".

We'll make this something people can participate in remotely, but we'll
also provide space (TBD, most likely at Mesosphere in San Francisco) for
the first one of these for anyone that would like to join in person.

Basic agenda will be for folks to get together to discuss where docs can be
improved, then break into teams to work on improving the docs, then come
back together for food/drinks and presentations on how we improved the docs
along with some prizes!

If you're interested in joining, please fill out this poll
.

Looking forward to improving the docs with everyone!

Re: Adding process::Executor::execute()

[Benjamin Hindman]

Quick clarification: you'll have a single `process::Executor` and queue up
all the rmdirs on that, correct? So you'll still tie up a worker thread,
but only one of them.

Either way it makes sense to add `process::Executor::execute()`. I'm happy
to shepherd that for you Chun, send me a patch!

On Mon, Sep 11, 2017 at 7:32 PM, Chun-Hung Hsiao 
wrote:

> Hi,
>
> I'm thinking about extending `process::Executor` with a new `execute()`
> interface.
> The need of this new interface surfaced when I'm working on
> https://issues.apache.org/jira/browse/MESOS-7964
> Summary:
> 1. A disk GC might execute multiple `rmdirs` callbacks, and some of them
> are heavy duty. We don't want to run them on `GarbageCollectorProcess` so
> that it won't block other events of the process.
> Currently we do the following:
> async(rmdirs).onAny(...);
> 2. `async` puts each `rmdir` callback in an actor. When there are many
> heavy-duty `rmdirs` callbacks, the actors end up occupying all worker
> threads and blocking other actors for minutes.
>
> Yan suggested me to use `process::Executor` such that:
> 1. The `rmdirs` callbacks are not executed on `GarbaceGollectorProcess`
> 2. All `rmdirs` callbacks are executed on a single thread
> Since the `Executor` class only contains a `defer()` function that returns
> a `_Deferred` structure,
> I'm doing the following:
> executor.defer(rmdirs).operator std::function(
> )>()().onAny(...)
>
> Would it make sense to add another `execute()` function to directly return
> a `Future`?
>
> - Chun-Hung
>
>


-- 
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos
Mesosphere Inc.  <http://www.mesosphere.io/>

Follow us on Twitter: @mesosphere <http://twitter.com/mesosphere>


 

08/31 community meeting agenda

[Benjamin Hindman]

Please see the doc

for
an up to date agenda and Hangouts links.

tl;dr; In addition to going over the community kanban board we'll also
discuss some upcoming changes and proposals around libprocess `Future`
discard and abandonment semantics. If you're hacking in Mesos or interested
to learn more about libprocess please join the meeting tomorrow at 3 PM PT!

Re: C++14 Upgrade

[Benjamin Hindman]

+1

We care about RHEL 6 / 7, anyone out there that has used a GCC 5 on these
can help MPark out?


On Thu, Jul 20, 2017 at 5:23 PM Michael Park  wrote:

> I've added Fedora 23 and OS X Sierra to the spreadsheet.
> I've also successfully compiled and ran `make check` with the following
> distros:
>
>- CentOS 6 / 7
>- Fedora 23
>- Ubuntu 12.04, 14.04, 15.04, 15.10, 16.04, 16.10
>
> I need help with:
>
>- Scientific Linux 6 / 7 (Does anyone actually care?)
>- RHEL 6 / 7 (Does anyone actually care?)
>
> I think Apple Clang has some issues currently that I'll be looking into
> myself.
>
> Thanks!
>
> MPark
>
> On Wed, Jul 19, 2017 at 3:53 PM Vinod Kone  wrote:
>
> > +1
> >
> > Can you also add info for OSX?
> >
> > On Wed, Jul 19, 2017 at 3:34 PM, Michael Park  wrote:
> >
> > > I'd like move us to C++14!
> > >
> > > The following I'd say are the important C++14 features for us:
> > >
> > >- Generic lambdas: [](const auto& x) { /* ... */ }
> > >- Extended lambda captures: [x = move(x)]() { /* ... */ }
> > >
> > > The following are some features that would be helpful for
> > libprocess/stout:
> > >
> > >- Function return type deduction
> > >- Relaxed constexpr functions
> > >- std::integer_sequence + other meta-programming facilities
> > >
> > > The minimum GCC version would become 5, and minimum VS would be 2017
> > > (deprecation of VS 2015 is already in progress). Clang 3.5 is our
> current
> > > minimum Clang and it already implements C++14 so there's nothing to do
> > > there.
> > >
> > > As a bonus, we pick up the  header which is C++11 but haven't
> been
> > > usable for us since it's not implemented in GCC 4.8.
> > >
> > > Here's the spreadsheet of available compilers from various distros and
> > how
> > > to get them:
> > > https://docs.google.com/spreadsheets/d/1ocQ19Uv1d8wdb-
> > > QL4fDRAiQ12gPQwL3cIAzuV0csYwM/edit#gid=0
> > >
> > > Please suggest more distros we should consider, and
> > > provide feedback with your concerns!
> > >
> > > Thanks,
> > >
> > > MPark
> > >
> >
>

Apache Mesos Survey

[Benjamin Hindman]

Share your thoughts in our Apache Mesos Survey

Apache Mesos has seen tremendous growth since its introduction in 2009, and
has been running in production at some of the largest Internet companies
like Twitter, Netflix, and NASA JPL for many years now.

Mesosphere is running a short survey to understand the usage of Apache
Mesos and the needs of users. An ever growing list of organizations are
using Mesos and contributing back to the community, and this survey helps
us understand how Apache Mesos is used and how to make it better.

A report with summary findings will be published at the conclusion of the
survey. All your responses will remain confidential and only the aggregate
statistics will be shared.

In appreciation, you will be entered to win one of THREE $200 Amazon gift
cards once you complete the survey .


Take the Survey 


Thank you and we hope to hear from you!

Sincerely,

Ben Hindman
Apache Mesos PMC Chair & Mesosphere Co-Founder



Mesosphere
88 Stevenson
San Francisco, CA 94105

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

[Benjamin Hindman]

I agree with Vinod that we should go with option 1. I think redirect is a
valuable feature but it's not imperative for the operation of the cluster.

On Tue, Jul 26, 2016 at 5:39 PM, Vinod Kone  wrote:

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

New Stack Survey

[Benjamin Hindman]

The New Stack is doing research into what container orchestration entails
and what systems are used for container orchestration, and we want the
Mesos community properly represented. Please represent the Mesos community
and fill out their survey .

They are trying to answer:

• What functionality do you expect to be in a container orchestration tool?
• Which projects, products, and services are considered for the management
of containers?
• What will be included in The New Stack’s updated directory of projects
and products?
The survey is anonymous and the results will be publicly available, so
please *participate now* .
Or, if you have trouble with the link, please paste this URL into your
browser: https://www.surveymonkey.com/r/tns2016.


Thank you all!

Re: Precision of scalar resources

[Benjamin Hindman]

SGTM, thanks Neil!

On Fri, Feb 12, 2016 at 2:25 PM, Neil Conway  wrote:

> tl;dr:
>
> If you use resource values with more than three decimal digits of
> precision (e.g., you are launching a task that uses 2.5001 CPUs),
> please speak up!
>
> 
>
> Mesos uses floating point to represent scalar resource values, such as
> the number of CPUs in a resource offer or dynamic reservation. The
> master does resource math in floating point, which leads to a few
> problems:
>
> * due to roundoff error, frameworks can receive offers that have
> unexpected resource values (e.g., MESOS-3990)
> * various internal assertions in the master can fail due to roundoff
> error (e.g., MESOS-3552).
>
> In the long term, we can solve these problems by switching to a
> fixed-point representation for scalar values. However, that will
> require a long deprecation cycle.
>
> In the short term, we should make floating point behavior more
> reliable. To do that, I propose:
>
> (1) Resource values will support AT MOST three decimal digits of
> precision. Additional precision in resource values will be discarded
> (via rounding).
>
> (2) The master will internally used a fixed-point representation to
> avoid unpredictable roundoff behavior.
>
> For more details, please see the design doc here:
>
> https://docs.google.com/document/d/14qLxjZsfIpfynbx0USLJR0GELSq8hdZJUWw6kaY_DXc
> -- comments welcome!
>
> Thanks,
> Neil
>

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

[Benjamin Hindman]

+1!

On Sun, Dec 13, 2015 at 10:46 AM, 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: Mesos Developer Community Design Discussions

[Benjamin Hindman]

The spreadsheet has been updated, sorry about that!

Dave: we didn't want to pull people away from the hackathon and all the
other times were taken, so we figured we'd do the best we can! Enough
people have chatted with me about talking about future features that it
made sense to put something together for anyone in the community to join.
We'll try and get live streaming set up for folks that aren't flying in
until Wednesday (or at all).

On Mon, Aug 10, 2015 at 3:01 PM Dave Lester  wrote:

> Hi Ben,
>
> It looks like the spreadsheet/google form isn't public outside your
> organization, you may need to revise the permissions.
>
> I'm curious, why this particular day? It's a bit unfortunate that only 8
> day notice is being given, since I imagine most people have their
> flights for MesosCon already booked and will not likely be in
> attendance.
>
> Best,
> Dave
>
> On Mon, Aug 10, 2015, at 02:52 PM, Benjamin Hindman wrote:
> > We've had great developer community meetings over Google Hangouts, but
> > MesosCon is right around the corner and we'd like to do it in person!
> >
> > I'd like to invite everyone to attend an in person developer community
> > meeting on Tuesday, August 18th in Seattle. The focus will be for Mesos
> > committers and contributors to get together to discuss "big ticket"
> > features to work on during the next 6 to 12 months. I will be joining
> > many
> > other committers at this event and we all look forward to discussing new
> > features with everyone!
> >
> > There is a limited amount of space so please submit your RSVP here:
> > http://bit.ly/mesosdesignsummit
> >
> > We look forward to seeing you in Seattle! And don't forget to register
> > for
> > MesosCon
> > <http://events.linuxfoundation.org/events/mesoscon/attend/register> if
> > you haven't already!
>

Mesos Developer Community Design Discussions

[Benjamin Hindman]

We've had great developer community meetings over Google Hangouts, but
MesosCon is right around the corner and we'd like to do it in person!

I'd like to invite everyone to attend an in person developer community
meeting on Tuesday, August 18th in Seattle. The focus will be for Mesos
committers and contributors to get together to discuss "big ticket"
features to work on during the next 6 to 12 months. I will be joining many
other committers at this event and we all look forward to discussing new
features with everyone!

There is a limited amount of space so please submit your RSVP here:
http://bit.ly/mesosdesignsummit

We look forward to seeing you in Seattle! And don't forget to register for
MesosCon  if
you haven't already!

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

[Benjamin Hindman]

+1 (binding)

On Ubuntu 14.04:

$ make check
... all tests pass ...
$ sudo make check
... tests with known issues fail, but ignoring because these have all been
resolved and are issues with the tests alone ...

Thanks Adam.

On Fri, Jul 17, 2015 at 4:42 PM Adam Bordelon  wrote:

> Hello Mesos community,
>
> Please vote on releasing the following candidate as Apache Mesos 0.23.0.
>
> 0.23.0 includes the following:
>
> 
> - Per-container network isolation
> - Dockerized slaves will properly recover Docker containers upon failover.
> - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
>
> as well as experimental support for:
> - Fetcher Caching
> - Revocable Resources
> - SSL encryption
> - Persistent Volumes
> - Dynamic Reservations
>
> 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.0-rc4
>
> 
>
> The candidate for Mesos 0.23.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz
>
> The tag to be voted on is 0.23.0-rc4:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.0-rc4
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.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-1062
>
> Please vote on releasing this package as Apache Mesos 0.23.0!
>
> The vote is open until Wed July 22nd, 17: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.23.0 (I've tested it!)
> [ ] -1 Do not release this package because ...
>
> Thanks,
> -Adam-
>
>

Re: Doxygen / Javadoc changes

[Benjamin Hindman]

We're only using non-javadoc comments for APIs, which are mostly in
headers. We're still using // based C++ comments in implementations and
places we don't want to be picked up via doxygen.

On Thu, Jul 9, 2015 at 5:23 PM Benjamin Mahler 
wrote:

> A couple of thoughts:
>
> (1) When introducing javadoc comments, can we please keep comment style
> consistent within files and APIs? For the most part, it seems folks are
> introducing javadoc in consistent sweeps, which is great. However, it looks
> also like there are reviews and commits where we are introducing javadoc +
> non-javadoc within a file / api, would love to avoid the inconsistency. :(
>
> (2) Where are we planning to introduce javadoc comments? APIs only? All
> headers? Would love to see some communication around how we'd like folks to
> be proceeding. Maybe I missed it, but can't seem to find an email with
> this.
>
> (3) I ask because there is a tradeoff: we make the code more verbose to
> navigate visually. Also, sometimes we document things unnecessarily:
>
> /**
>  * Sends a message with data without a return address.
>  *
>  * @param to Receiver of the message.
>  * @param name Name of the message.
>  * @param data Data to send (gets copied).
>  * @param length Length of data.
>  */
> void post(const UPID& to,
>   const std::string& name,
>   const char* data = NULL,
>   size_t length = 0);
>
> Here, having a 'to' or 'receiver' as a variable name is pretty
> self-evident, ditto for 'messageName', 'data', 'length'. Are we ok with
> omitting these kinds of comments? It seems like we have to be asking
> ourselves when this provides value. Thoughts?
>
> Ben
>

Re: synchronized

[Benjamin Hindman]

One more thing I'd like to point out here that MPark neglected because he's
too humble: *the latest implementation of the synchronized macro enables us
to use a return statement within the block without having to add the
'UNREACHABLE();' statement after the block!*

I haven't seen it done in other projects that have a similar macros, very
cool stuff MPark! Thank you!


On Thu, Jul 9, 2015 at 5:02 PM Benjamin Mahler 
wrote:

> Thanks Michael, please do keep sending things like this out, and encourage
> others to do so as well.
>
> Going to be increasingly important to let each other know about things like
> this as the community grows. :)
>
> On Thu, Jul 9, 2015 at 4:37 PM, Marco Massenzio 
> wrote:
>
> > sweet!
> >
> > *Marco Massenzio*
> > *Distributed Systems Engineer*
> >
> > On Wed, Jul 8, 2015 at 12:40 PM, Michael Park  wrote:
> >
> > > Hello,
> > >
> > > This is an announcement about our *synchronized* macro available in
> > > **. *synchronized* is essentially a syntactic
> > sugar
> > > to the *std::lock_guard* pattern that is reminiscent of Java's
> > > *synchronized*.
> > >
> > > With *std::lock_guard*:
> > >
> > > *  std::mutex m;*
> > > *  {*
> > > *std::lock_guard lock(m);  **// Acquire.*
> > > *// Do something under the lock.*
> > > *  }  **// Release.*
> > >
> > > With *synchronized*:
> > >
> > > *  std::mutex m;*
> > > *  synchronized (m) {**  // Acquire.*
> > > *// Do something under the lock.*
> > > *  }**  // Release.*
> > >
> > > *synchronized* is currently supported for
> > >
> > >- Any *T* that has *T::lock()* and *T::unlock()* (practically these
> > >include *std::mutex, std::recursive_mutex*, etc)
> > >- *std::atomic_flag* (remember to initialize it to
> *ATOMIC_FLAG_INIT*)
> > >- *pthread_mutex_t* (we'll be deprecating this as soon as possible)
> > >
> > > If you find that you need additional support for your lock type *T*,
> you
> > > can add it easily by adding a *synchronize* function. It should follow
> > this
> > > pattern:
> > >
> > > *  Synchronized synchronize(T* t)*
> > > *  {*
> > > *return Synchronized(*
> > > *t,*
> > > *[](T *t) { /* lock 't'. */ },*
> > > *[](T *t) { /* unlock 't'. */ });*
> > > *  }*
> > >
> > > Great example of this is available in
> > > *3rdparty/libprocess/src/libevent_ssl_socket.hpp
> > > *for customized locking of *libevent*'s *bufferevent*.
> > >
> > > *  Synchronized synchronize(bufferevent* bev)*
> > > *  {*
> > > *return Synchronized(*
> > > *bev,*
> > >  *   [](bufferevent* bev) { bufferevent_lock(bev); },*
> > > *[](bufferevent* bev) { bufferevent_unlock(bev); });*
> > > *  }*
> > >
> > > We use this mechanism consistently throughout the codebase, and would
> > like
> > > it to be the standard pattern for locking critical sections.
> > >
> > > Thanks,
> > >
> > > MPark.
> > >
> >
>

Re: Mesos Jira workflow

[Benjamin Hindman]

+1 This sounds great to me Marco. I love eliminating Reopened, as well as
simplifying (constraining) other transitions. I couple of quick questions:

Why does stoping progress go from In Progress back to Open instead of
Accepted? Seems like it's still an Accepted issue just not being worked on.

Can we resolve or close something directly from Open? For example, issues
we're never going to work on or are duplicates or already fixed, etc.

Do we need both Resolved and Closed? This has come up in the past, we tend
to close issues after we cut a release with them, but it's kind of an extra
step that I'm not convinced we really need to do.



On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio  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:
>
> [image: Inline image 1]
>
> (spaghetti workflow? :)
>
> I would propose to simplify it to the following:
>
> [image: Inline image 2]
>
> 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: soliciting shepherds for auto tools changes

[Benjamin Hindman]

Took care of MESOS-2666 as well James. There was a bug I had to fix. ;-)
Please take a look at the reviews where I left some comments.

It looks like Cody still has some questions around semantics for
https://reviews.apache.org/r/33752, please address that and then we can get
it committed.

Thank you thank you thank you for reaching out for a shepherd too!


On Thu, Jun 4, 2015 at 7:00 AM Benjamin Hindman 
wrote:

> I just took a look and shipped the reviews associated with MESOS-2659.
> I'll take a look at MESOS-2666 next. Thanks for the contributions James!
>
>
> On Thu, Jun 4, 2015 at 5:54 AM Jake Farrell  wrote:
>
>> I can only help review, not a Mesos committer
>>
>> -Jake
>>
>>
>>
>> On Wed, Jun 3, 2015 at 11:47 PM, James Peach  wrote:
>>
>> >
>> > > On Jun 3, 2015, at 10:25 AM, Jake Farrell 
>> wrote:
>> > >
>> > > Happy to help review and provide feedback on these patches
>> >
>> > Thanks Jake, does that mean you are shepherding too, or just reviewing?
>> >
>> > >
>> > > -Jake
>> > >
>> > > On Wed, Jun 3, 2015 at 12:21 PM, James Peach 
>> wrote:
>> > >
>> > >>
>> > >>> On May 18, 2015, at 10:52 AM, Vinod Kone 
>> wrote:
>> > >>>
>> > >>> Tim and Cody. Do any of you have cycles to shepherd these?
>> > >>
>> > >> If there's no takers, should I just close the tickets?
>> > >>
>> > >>>
>> > >>> On Fri, May 15, 2015 at 3:19 PM, Vinod Kone 
>> > wrote:
>> > >>>
>> > >>>>
>> > >>>>
>> > >>>> -- Vinod
>> > >>>>
>> > >>>> -- Forwarded message --
>> > >>>> From: James Peach 
>> > >>>> Date: Fri, May 15, 2015 at 9:28 AM
>> > >>>> Subject: soliciting shepherds for auto tools changes
>> > >>>> To: benjamin.mah...@gmail.com, c...@mesosphere.io,
>> > tstcl...@redhat.com,
>> > >>>> benjamin.hind...@gmail.com, vinodk...@gmail.com, mcyp...@gmail.com
>> > >>>>
>> > >>>>
>> > >>>> Hi all,
>> > >>>>
>> > >>>> I have the following tickets:
>> > >>>>   https://issues.apache.org/jira/browse/MESOS-2537
>> > >>>>   https://issues.apache.org/jira/browse/MESOS-2659
>> > >>>>   https://issues.apache.org/jira/browse/MESOS-2666
>> > >>>>
>> > >>>> with corresponding reviews at:
>> > >>>>   https://reviews.apache.org/r/33755/
>> > >>>>   https://reviews.apache.org/r/33754/
>> > >>>>   https://reviews.apache.org/r/33753/
>> > >>>>   https://reviews.apache.org/r/33752/
>> > >>>>   https://reviews.apache.org/r/33850/
>> > >>>>   https://reviews.apache.org/r/33849/
>> > >>>>
>> > >>>> Is anyone able to act as shepherd for these?
>> > >>>>
>> > >>>> thanks,
>> > >>>> James
>> > >>>>
>> > >>>>
>> > >>
>> > >>
>> >
>> >
>>
>

Re: soliciting shepherds for auto tools changes

[Benjamin Hindman]

I just took a look and shipped the reviews associated with MESOS-2659. I'll
take a look at MESOS-2666 next. Thanks for the contributions James!


On Thu, Jun 4, 2015 at 5:54 AM Jake Farrell  wrote:

> I can only help review, not a Mesos committer
>
> -Jake
>
>
>
> On Wed, Jun 3, 2015 at 11:47 PM, James Peach  wrote:
>
> >
> > > On Jun 3, 2015, at 10:25 AM, Jake Farrell  wrote:
> > >
> > > Happy to help review and provide feedback on these patches
> >
> > Thanks Jake, does that mean you are shepherding too, or just reviewing?
> >
> > >
> > > -Jake
> > >
> > > On Wed, Jun 3, 2015 at 12:21 PM, James Peach  wrote:
> > >
> > >>
> > >>> On May 18, 2015, at 10:52 AM, Vinod Kone 
> wrote:
> > >>>
> > >>> Tim and Cody. Do any of you have cycles to shepherd these?
> > >>
> > >> If there's no takers, should I just close the tickets?
> > >>
> > >>>
> > >>> On Fri, May 15, 2015 at 3:19 PM, Vinod Kone 
> > wrote:
> > >>>
> > 
> > 
> >  -- Vinod
> > 
> >  -- Forwarded message --
> >  From: James Peach 
> >  Date: Fri, May 15, 2015 at 9:28 AM
> >  Subject: soliciting shepherds for auto tools changes
> >  To: benjamin.mah...@gmail.com, c...@mesosphere.io,
> > tstcl...@redhat.com,
> >  benjamin.hind...@gmail.com, vinodk...@gmail.com, mcyp...@gmail.com
> > 
> > 
> >  Hi all,
> > 
> >  I have the following tickets:
> >    https://issues.apache.org/jira/browse/MESOS-2537
> >    https://issues.apache.org/jira/browse/MESOS-2659
> >    https://issues.apache.org/jira/browse/MESOS-2666
> > 
> >  with corresponding reviews at:
> >    https://reviews.apache.org/r/33755/
> >    https://reviews.apache.org/r/33754/
> >    https://reviews.apache.org/r/33753/
> >    https://reviews.apache.org/r/33752/
> >    https://reviews.apache.org/r/33850/
> >    https://reviews.apache.org/r/33849/
> > 
> >  Is anyone able to act as shepherd for these?
> > 
> >  thanks,
> >  James
> > 
> > 
> > >>
> > >>
> >
> >
>

Re: [Style Proposal] Mesos Header Include Order: Follow Google Style Guide completely

[Benjamin Hindman]

And yes, in this case, unlike the s/> >/>>/ let's go ahead and do a global
cleanup.

On Sat, May 2, 2015 at 5:19 PM, Benjamin Hindman  wrote:

> I'm a definite +1 on this too!
>
> On Fri, May 1, 2015 at 2:13 PM, Benjamin Mahler  > wrote:
>
>> I'm a +1 on this so long as you follow up with all of the necessary
>> include changes. :)
>> BenH was probably the one that initially enacted this style, so I've
>> cc'ed him to see if there was intention behind it.
>>
>> It should be pointed out that this rule doesn't apply to all .cpp files,
>> yes? (e.g. tests don't have a corresponding header).
>>
>> On Wed, Apr 29, 2015 at 1:35 PM, Jörg Schad  wrote:
>>
>>> I would like to propose that regarding the header include order we follow
>>> the Google Styleguide completely. We currently have an undocumented
>>> exception in that we do not include direct headers first in the
>>> corresponding implementation files (i.e. abc.hpp -> abc.cpp).
>>>
>>> The reasons, and examples for this are outlined in the Jira here:
>>> https://issues.apache.org/jira/browse/MESOS-2673
>>>
>>> Please feel free to comment here on the dev-list, but also consider to
>>> comment on the Review Request directly!
>>>
>>> Thanks for your feedback,
>>> Jörg
>>>
>>
>>
>
>
> --
> Benjamin Hindman
> Founder of Mesosphere and Co-Creator of Apache Mesos
> Mesosphere Inc.  <http://www.mesosphere.io/>
>
> Follow us on Twitter: @mesosphere <http://twitter.com/mesosphere>
>



-- 
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos
Mesosphere Inc.  <http://www.mesosphere.io/>

Follow us on Twitter: @mesosphere <http://twitter.com/mesosphere>

Re: [Style Proposal] Mesos Header Include Order: Follow Google Style Guide completely

[Benjamin Hindman]

I'm a definite +1 on this too!

On Fri, May 1, 2015 at 2:13 PM, Benjamin Mahler 
wrote:

> I'm a +1 on this so long as you follow up with all of the necessary
> include changes. :)
> BenH was probably the one that initially enacted this style, so I've cc'ed
> him to see if there was intention behind it.
>
> It should be pointed out that this rule doesn't apply to all .cpp files,
> yes? (e.g. tests don't have a corresponding header).
>
> On Wed, Apr 29, 2015 at 1:35 PM, Jörg Schad  wrote:
>
>> I would like to propose that regarding the header include order we follow
>> the Google Styleguide completely. We currently have an undocumented
>> exception in that we do not include direct headers first in the
>> corresponding implementation files (i.e. abc.hpp -> abc.cpp).
>>
>> The reasons, and examples for this are outlined in the Jira here:
>> https://issues.apache.org/jira/browse/MESOS-2673
>>
>> Please feel free to comment here on the dev-list, but also consider to
>> comment on the Review Request directly!
>>
>> Thanks for your feedback,
>> Jörg
>>
>
>


-- 
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos
Mesosphere Inc.  <http://www.mesosphere.io/>

Follow us on Twitter: @mesosphere <http://twitter.com/mesosphere>

C++11 lambdas have landed!

[Benjamin Hindman]

Please check out the style guide, and start using them! As we run into any
issues let's get the style guide updated please! Long time coming!

Re: [2/2] mesos git commit: Warn if g++ < 4.8 or a C++ standard library is too old for Mesos.

[Benjamin Hindman]

That would be great James! We took an MVP approach for now, but it would be
great if we could give even better error messages or warning messages for
compilers that we don't regularly test or work with.

On Sun, Apr 26, 2015 at 11:51 AM, James Peach  wrote:

> On Apr 25, 2015, at 4:24 PM, b...@apache.org wrote:
> >
> > Warn if g++ < 4.8 or a C++ standard library is too old for Mesos.
> >
> > After this a whole bunch more of the C++11 checks can be removed, we
> > can unconditionally use -std=c++11, among other things with this
> > change.
> >
> > Note that we don't explicitly check the clang version number since
> > extracting it is hard (OS X clang behaves differently than Linux
> > clang), and 'clang -dumpversion' always reports 4.2.1 for
> > compatibility with some random tools that used GCC.
>
> Would it make sense to use AX_COMPILER_VENDOR and AX_COMPILER_VERSION here?
>
>
> http://www.gnu.org/software/autoconf-archive/ax_compiler_vendor.html
>
> http://www.gnu.org/software/autoconf-archive/ax_compiler_version.html
>
> J
>

builds now require gcc 4.8+ or clang 3.5+

[Benjamin Hindman]

I'm happy to announce that we've committed the updates to configure.ac that
require gcc 4.8+ and clang 3.5+! See this thread

for
the discussion. Stay tuned for reviews updating the style guide with our
plans for using C++11 features. It's been a long time coming!

JIRA backlog grooming

[Benjamin Hindman]

Folks,

We're trying to do some backlog grooming in JIRA! You can all help us:

*Do you have an issue that is assigned to you but still in the 'Open'
state?* Please either (1) unassign this ticket or (2) move this issue into
'Accepted' or better 'In Progress' if you're actually working on this issue!

Thank you!

Ben.

Re: Review Request 33318: Fix docker containerizer usage and test.

[Benjamin Hindman]

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

Ship it!



src/slave/containerizer/docker.hpp
<https://reviews.apache.org/r/33318/#comment130546>

There is a big global invariant here that we should call out even more 
explicitly for future readers of the code. That is, we add the initial task 
resources to the ExecutorInfo so that the initial container we create is big 
enough since some ExecutorInfo's might not actually add resources. This is an 
unfortunate wart that got added that we should really clean up at some point 
(basically, we shouldn't need to have the Slave add the tasks resources to the 
ExecutorInfo because the Containerizer should just be able to figure that out 
itself). In the mean time, we should have a better comment and even:

if (task.isSome()) {
  CHECK(executor.resources() >= task.get().resources());
}


- Benjamin Hindman


On April 17, 2015, 6:21 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33318/
> ---
> 
> (Updated April 17, 2015, 6:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fix docker containerizer usage and test.
> The docker usage test is failing with the most recent change in including 
> executor resources in docker containerizer.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/docker.hpp 6893684e6d199a5d69fc8bba8e60c4acaae9c3c9 
>   src/tests/docker_containerizer_tests.cpp 
> c772d4c836de18b0e87636cb42200356d24ec73d 
> 
> Diff: https://reviews.apache.org/r/33318/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 32961: Allow framework re-registeration to update master http fields.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On April 14, 2015, 4:30 p.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32961/
> ---
> 
> (Updated April 14, 2015, 4:30 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1218, MESOS-2614 and MESOS-703
> https://issues.apache.org/jira/browse/MESOS-1218
> https://issues.apache.org/jira/browse/MESOS-2614
> https://issues.apache.org/jira/browse/MESOS-703
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Fields: 'name', 'hostname', 'failover_timeout', 'webui_url'
> 
> 
> Diffs
> -
> 
>   src/master/master.hpp 6141917644b84edfed9836fa0a005d55a36880e3 
>   src/master/master.cpp 44b0a0147f5354824d86332a67b30018634c9a36 
> 
> Diff: https://reviews.apache.org/r/32961/diff/
> 
> 
> Testing
> ---
> 
> make check.
> re-registered no_executor_framework with different 'name', 'hostname', 
> 'failover_timeout', and 'webui_url'
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Re: Suggestion: Mesos 0.22.1 point release

[Benjamin Hindman]

Yes, fixing it in 0.23.0 SGTM.

On Tue, Apr 14, 2015 at 10:02 PM, Jie Yu  wrote:

> I am just asking if you guys want to fix that for 0.22.1 or not. It sounds
> to me a non trivial fix. Given the bug is there for quite a while, maybe we
> can fix it in 0.23.0?
>
> - Jie
>
> On Tue, Apr 14, 2015 at 9:55 PM, Benjamin Hindman 
> wrote:
>
> > We are going to include MESOS-2614 (it's a really trivial fix).
> >
> > Jie, where did you get MESOS-2601 from? That's definitely not in the
> > spreadsheet.
> >
> > On Tue, Apr 14, 2015 at 7:40 PM, Jie Yu  wrote:
> >
> > > Also, this one:
> > > https://issues.apache.org/jira/browse/MESOS-2601
> > >
> > > This sounds like a non trivial fix.
> > >
> > > - Jie
> > >
> > > On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler <
> > > benjamin.mah...@gmail.com>
> > > wrote:
> > >
> > > >  Per Nik's comment here:
> > > >
> > > > Based on input from Vinod and Adam; I will reduce the scope on the
> > point
> > > > > release to focus on MESOS-1795 and MESOS-2583.
> > > > > I will move the other tickets back to 0.23.0 if you don't have any
> > > > > objections - let me know if you have any tickets which were
> > regressions
> > > > in
> > > > > 0.22.0.
> > > >
> > > >
> > > > I expected there to be fewer tickets in the spreadsheet, are the
> extra
> > > > tickets (e.g. https://issues.apache.org/jira/browse/MESOS-2614)
> going
> > to
> > > > be
> > > > included after all?
> > > >
> > > > On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere <
> > > jo...@mesosphere.io
> > > > >
> > > > wrote:
> > > >
> > > > > I think the plan is to cut a new RC by sometime tomorrow. The
> > > spreadsheet
> > > > > is up-to-date, just need to cherry-pick and modify the change-log.
> > > > >
> > > > > Joris
> > > > >
> > > > > On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler <
> > > > > benjamin.mah...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hey Nik, any progress on this? Is the spreadsheet up-to-date?
> > > > > >
> > > > > > On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon <
> a...@mesosphere.io>
> > > > > wrote:
> > > > > >
> > > > > > > Hi Adam,
> > > > > > >
> > > > > > > Yes, once we have finalized the scope of the point release,
> > Niklas
> > > > will
> > > > > > > send out an announcement of Mesos 0.22.1-rc1 (release
> candidate)
> > > > which
> > > > > we
> > > > > > > would love you to test any way you can. The email will contain
> > > > > > instructions
> > > > > > > for building the release candidate and voting in the thread.
> See
> > > the
> > > > > vote
> > > > > > > thread from 0.22.0-rc4 (became final):
> > > > > > >
> http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html
> > > > > > >
> > > > > > > The current thread is to collect suggestions for bug fixes to
> > > include
> > > > > in
> > > > > > > this point release.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > -Adam-
> > > > > > >
> > > > > > > On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla 
> > wrote:
> > > > > > >
> > > > > > > > On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen <
> > > > nik...@mesosphere.io
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Based on input from Vinod and Adam; I will reduce the scope
> > on
> > > > the
> > > > > > > point
> > > > > > > > > release to focus on MESOS-1795 and MESOS-2583.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Can I help test these in any way?
> > > > > > > >
> > > > > > > > --
> > > > > > > > /adam
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Suggestion: Mesos 0.22.1 point release

[Benjamin Hindman]

We are going to include MESOS-2614 (it's a really trivial fix).

Jie, where did you get MESOS-2601 from? That's definitely not in the
spreadsheet.

On Tue, Apr 14, 2015 at 7:40 PM, Jie Yu  wrote:

> Also, this one:
> https://issues.apache.org/jira/browse/MESOS-2601
>
> This sounds like a non trivial fix.
>
> - Jie
>
> On Tue, Apr 14, 2015 at 6:35 PM, Benjamin Mahler <
> benjamin.mah...@gmail.com>
> wrote:
>
> >  Per Nik's comment here:
> >
> > Based on input from Vinod and Adam; I will reduce the scope on the point
> > > release to focus on MESOS-1795 and MESOS-2583.
> > > I will move the other tickets back to 0.23.0 if you don't have any
> > > objections - let me know if you have any tickets which were regressions
> > in
> > > 0.22.0.
> >
> >
> > I expected there to be fewer tickets in the spreadsheet, are the extra
> > tickets (e.g. https://issues.apache.org/jira/browse/MESOS-2614) going to
> > be
> > included after all?
> >
> > On Tue, Apr 14, 2015 at 6:20 PM, Joris Van Remoortere <
> jo...@mesosphere.io
> > >
> > wrote:
> >
> > > I think the plan is to cut a new RC by sometime tomorrow. The
> spreadsheet
> > > is up-to-date, just need to cherry-pick and modify the change-log.
> > >
> > > Joris
> > >
> > > On Tue, Apr 14, 2015 at 5:37 PM, Benjamin Mahler <
> > > benjamin.mah...@gmail.com>
> > > wrote:
> > >
> > > > Hey Nik, any progress on this? Is the spreadsheet up-to-date?
> > > >
> > > > On Wed, Apr 8, 2015 at 1:00 AM, Adam Bordelon 
> > > wrote:
> > > >
> > > > > Hi Adam,
> > > > >
> > > > > Yes, once we have finalized the scope of the point release, Niklas
> > will
> > > > > send out an announcement of Mesos 0.22.1-rc1 (release candidate)
> > which
> > > we
> > > > > would love you to test any way you can. The email will contain
> > > > instructions
> > > > > for building the release candidate and voting in the thread. See
> the
> > > vote
> > > > > thread from 0.22.0-rc4 (became final):
> > > > > http://www.mail-archive.com/dev%40mesos.apache.org/msg30668.html
> > > > >
> > > > > The current thread is to collect suggestions for bug fixes to
> include
> > > in
> > > > > this point release.
> > > > >
> > > > > Cheers,
> > > > > -Adam-
> > > > >
> > > > > On Tue, Apr 7, 2015 at 9:22 AM, Adam Avilla  wrote:
> > > > >
> > > > > > On Fri, Apr 3, 2015 at 3:47 PM, Niklas Nielsen <
> > nik...@mesosphere.io
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Based on input from Vinod and Adam; I will reduce the scope on
> > the
> > > > > point
> > > > > > > release to focus on MESOS-1795 and MESOS-2583.
> > > > > > >
> > > > > >
> > > > > > Can I help test these in any way?
> > > > > >
> > > > > > --
> > > > > > /adam
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Review Request 32911: Fixed sandbox ownership bug for executors without URIs.

[Benjamin Hindman]

> On April 7, 2015, 1:17 a.m., Joris Van Remoortere wrote:
> > src/slave/containerizer/external_containerizer.cpp, line 374
> > <https://reviews.apache.org/r/32911/diff/1/?file=918552#file918552line374>
> >
> > Can we remove the capture by reference here? I know it's not in the 
> > style guide yet, but it will likely be accepted.

+1


- Benjamin


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


On April 7, 2015, 12:40 a.m., Niklas Nielsen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32911/
> ---
> 
> (Updated April 7, 2015, 12:40 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ian Downes.
> 
> 
> Bugs: MESOS-2592
> https://issues.apache.org/jira/browse/MESOS-2592
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> During recent refactorings, executor directory ownership was delegated to the 
> fetcher. However, the fetcher is not invoked if no URIs are present in the 
> executor or task command. This left some of these tasks broken as the 
> directory ownership defaulted to the mesos-slave's (root).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/external_containerizer.cpp 
> 1bbd61cb096771b7e4a1350079f79a20102e78f9 
>   src/slave/paths.hpp 1618439d728ded347ec75317ce8dd998acd7ee94 
>   src/slave/paths.cpp 01ea856aa2e628d4aee5fd31f7e49d147f740e8f 
>   src/slave/slave.cpp 521624c335b9110e12ee1ff21c3918e5af6a2bde 
> 
> Diff: https://reviews.apache.org/r/32911/diff/
> 
> 
> Testing
> ---
> 
> Functional tests with mesos-execute and make check. Have created JIRA's for 
> introduction of more permission/user tests.
> 
> 
> Thanks,
> 
> Niklas Nielsen
> 
>

Re: Review Request 32911: Fixed sandbox ownership bug for executors without URIs.

[Benjamin Hindman]

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

Ship it!



src/slave/paths.cpp
<https://reviews.apache.org/r/32911/#comment128225>

Let's move the TODO into the body of the 'if' (closer to where the error 
checking is) and then add a comment above this 'if' that explains that we need 
to alays 'chown' the directory so that the permissions are correct. Feel free 
to go as far as noting the JIRA issue and that this had worked in the past 
because the fetcher was doing it but sometimes we won't be fetching anything 
hence the need to always do it here.

Also, I'm guessing all containerizers call 'createExecutorPath' except the 
ExternalContainerizer?



src/slave/slave.cpp
<https://reviews.apache.org/r/32911/#comment128223>

Great comment! Can we also add something to the end of the comment that 
says that the user is validated when the task goes through the master? Thanks!



src/slave/slave.cpp
<https://reviews.apache.org/r/32911/#comment128224>

Why don't you need to check the taskInfo? Is it because we should have set 
the executorInfo's 'user' appropriately? If so, let's comment as much, even 
going as far as introducing a CHECK!


- Benjamin Hindman


On April 7, 2015, 12:40 a.m., Niklas Nielsen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32911/
> -------
> 
> (Updated April 7, 2015, 12:40 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ian Downes.
> 
> 
> Bugs: MESOS-2592
> https://issues.apache.org/jira/browse/MESOS-2592
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> During recent refactorings, executor directory ownership was delegated to the 
> fetcher. However, the fetcher is not invoked if no URIs are present in the 
> executor or task command. This left some of these tasks broken as the 
> directory ownership defaulted to the mesos-slave's (root).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/external_containerizer.cpp 
> 1bbd61cb096771b7e4a1350079f79a20102e78f9 
>   src/slave/paths.hpp 1618439d728ded347ec75317ce8dd998acd7ee94 
>   src/slave/paths.cpp 01ea856aa2e628d4aee5fd31f7e49d147f740e8f 
>   src/slave/slave.cpp 521624c335b9110e12ee1ff21c3918e5af6a2bde 
> 
> Diff: https://reviews.apache.org/r/32911/diff/
> 
> 
> Testing
> ---
> 
> Functional tests with mesos-execute and make check. Have created JIRA's for 
> introduction of more permission/user tests.
> 
> 
> Thanks,
> 
> Niklas Nielsen
> 
>

Re: Review Request 32797: Kill the executor when docker container is destroyed.

[Benjamin Hindman]

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

Ship it!


I had another thought after my first review, see below please!


src/slave/containerizer/docker.cpp
<https://reviews.apache.org/r/32797/#comment127813>

Why kill the executor before doing Docker::stop? Can you comment here why 
you do it in this order versus the other order and the ramifications that has?


- Benjamin Hindman


On April 2, 2015, 11:38 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32797/
> ---
> 
> (Updated April 2, 2015, 11:38 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Bugs: MESOS-2583
> https://issues.apache.org/jira/browse/MESOS-2583
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Kill the executor when docker container is destroyed.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp e83b912c707a3f2687b09a647a9ed248a940ea97 
> 
> Diff: https://reviews.apache.org/r/32797/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 32798: Add test to verify executor clean up in docker containerizer.

[Benjamin Hindman]

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

Ship it!



src/tests/docker_containerizer_tests.cpp
<https://reviews.apache.org/r/32798/#comment127812>

My only question here is how do you know the executor is properly killed 
and cleaned up? Is this because you know there aren't any more child processes? 
Is that something you want to check after you call Shutdown()? I.e., 
os::children(0).get().empty() or something like that?


- Benjamin Hindman


On April 2, 2015, 11:38 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32798/
> ---
> 
> (Updated April 2, 2015, 11:38 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Bugs: MESOS-2583
> https://issues.apache.org/jira/browse/MESOS-2583
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Add test to verify executor clean up in docker containerizer.
> 
> 
> Diffs
> -
> 
>   src/tests/docker_containerizer_tests.cpp 
> fdd706a892ee1c8d55a406b3f956d99c076c623b 
> 
> Diff: https://reviews.apache.org/r/32798/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 32797: Kill the executor when docker container is destroyed.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On April 2, 2015, 11:38 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32797/
> ---
> 
> (Updated April 2, 2015, 11:38 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Bugs: MESOS-2583
> https://issues.apache.org/jira/browse/MESOS-2583
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Kill the executor when docker container is destroyed.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp e83b912c707a3f2687b09a647a9ed248a940ea97 
> 
> Diff: https://reviews.apache.org/r/32797/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Review Request 32796: Only update docker container when resources differs.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On April 2, 2015, 11:37 p.m., Timothy Chen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32796/
> ---
> 
> (Updated April 2, 2015, 11:37 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Bernd Mathiske, and Till 
> Toenshoff.
> 
> 
> Bugs: MESOS-2583
> https://issues.apache.org/jira/browse/MESOS-2583
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Only update docker container when resources differs.
> Also include the executor resources when launching the docker container to 
> avoid updating it again later on.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp e83b912c707a3f2687b09a647a9ed248a940ea97 
> 
> Diff: https://reviews.apache.org/r/32796/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Timothy Chen
> 
>

Re: Suggestion: Mesos 0.22.1 point release

[Benjamin Hindman]

Obviously a +1, this is a stability fix we should get to our users as soon
as possible.

On Mon, Mar 30, 2015 at 9:01 PM, Niklas Nielsen 
wrote:

> Hi all,
>
> Joris and Ben H recently located and fixed a resident bug in the state
> abstraction which caused many crashes in the JVM (mostly in conjunction
> with Marathon) at scale (https://issues.apache.org/jira/browse/MESOS-1795)
>
> We therefore wanted to suggest doing a point release with this fix
> alongside any high-impact fixes which may have landed between the 0.22.0
> release and now (or if reviewable and landed within a couple of days). It
> should be a release we can do in one to two weeks; otherwise, we should
> just wait for 0.23.0
>
> Any thoughts/input?
>
> Cheers,
> Niklas
>

Re: Review Request 32151: Add MESOS_{MAJOR|MINOR|PATCH}_VERSION to libmesos.

[Benjamin Hindman]

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

Ship it!



src/common/version.cpp
<https://reviews.apache.org/r/32151/#comment126502>

Let's include:

<< " failed to parse Mesos version '" << MESOS_VERSION << "'";

Here and below please!



src/common/version.cpp
<https://reviews.apache.org/r/32151/#comment126508>

Let's just:

return version->get().major;

Here and below please.



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126510>

This should all be Javadoc comments (/** */).



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126485>

s/new/New/



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126486>

s/old/Old/



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126496>

implements Comparable



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126511>

Javadoc comments please, here and everywhere else!



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126497>

@Override



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126500>

if (other == null) {
  throw new IllegalArgumentException("other Version must not be null");
}

if (major < other.major) {
  return -1;
} else if (major > other.major) {
  return 1;
}

if (minor < other.minor) {
  return -1;
} else if (minor > other.minor) {
  return 1;
}

...



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126509>

Let's leave a comment that this is not "equal to and before" but just 
strictly before, similar down below for 'after' as well.



src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in
<https://reviews.apache.org/r/32151/#comment126491>

Let's make this a RuntimeException instead. Why? This provides similar 
semantics to if we attempted to call a native method and haven't first called 
MesosNativeLibrary.load().


- Benjamin Hindman


On March 27, 2015, 12:01 a.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32151/
> ---
> 
> (Updated March 27, 2015, 12:01 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1795 and MESOS-2161
> https://issues.apache.org/jira/browse/MESOS-1795
> https://issues.apache.org/jira/browse/MESOS-2161
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   include/mesos/version.hpp.in 524cebce5d84edac3ef5d0b72e3989f283164809 
>   src/Makefile.am 7a06c7028eca8164b1f5fdea6a7ecd37ee6826bb 
>   src/common/version.cpp PRE-CREATION 
>   src/java/generated/org/apache/mesos/MesosNativeLibrary.java.in 
> 668647fdfc0e203fcde59263256659ba14e29960 
>   src/java/jni/org_apache_mesos_MesosNativeLibrary.cpp PRE-CREATION 
>   src/tests/common/version_tests.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/32151/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Re: Review Request 32152: Fix memory corruption in AbstractState JNI bindings. MESOS-2161.

[Benjamin Hindman]

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

Ship it!



src/java/jni/org_apache_mesos_state_AbstractState.cpp
<https://reviews.apache.org/r/32152/#comment126525>

s/.././



src/java/jni/org_apache_mesos_state_AbstractState.cpp
<https://reviews.apache.org/r/32152/#comment126519>

Can we confirm that we can make a jclass be static?



src/java/jni/org_apache_mesos_state_AbstractState.cpp
<https://reviews.apache.org/r/32152/#comment126524>

Please add a minor comment above each of these 'return' lines that says 
something like:

// NOTE: See TODO at top of file for why we proxy.



src/java/jni/org_apache_mesos_state_AbstractState.cpp
<https://reviews.apache.org/r/32152/#comment126523>

4 space indent



src/java/jni/org_apache_mesos_state_AbstractState.cpp
<https://reviews.apache.org/r/32152/#comment126517>

Kill whitespace please.



src/java/src/org/apache/mesos/state/AbstractState.java
<https://reviews.apache.org/r/32152/#comment126520>

Can kill the 'try' once we change 
MesosNativeLibrary.LibraryNotLoadedException to RuntimeException. Here and 
below.


- Benjamin Hindman


On March 27, 2015, 12:02 a.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32152/
> ---
> 
> (Updated March 27, 2015, 12:02 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1795 and MESOS-2161
> https://issues.apache.org/jira/browse/MESOS-1795
> https://issues.apache.org/jira/browse/MESOS-2161
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/java/jni/org_apache_mesos_state_AbstractState.cpp 
> 1accc8a498a68b7cfd9e39dc1f3ce01c8bfd219f 
>   src/java/src/org/apache/mesos/state/AbstractState.java 
> c66bf0519e7fc671d1e167ccd1e778dc65d3d8e6 
> 
> Diff: https://reviews.apache.org/r/32152/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Re: Review Request 32550: Add major, minor, and patch accessors to stout's Version.

[Benjamin Hindman]

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

Ship it!



3rdparty/libprocess/3rdparty/stout/include/stout/version.hpp
<https://reviews.apache.org/r/32550/#comment126483>

These are const, let's just expose them as fields (without the _), like we 
do for os::Release.


- Benjamin Hindman


On March 27, 2015, 12:01 a.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/32550/
> ---
> 
> (Updated March 27, 2015, 12:01 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1795 and MESOS-2161
> https://issues.apache.org/jira/browse/MESOS-1795
> https://issues.apache.org/jira/browse/MESOS-2161
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> We called them majorVersion, minorVersion, and patchVersion to avoid 
> conflicting with major() and minor() (http://man.he.net/man3/gnu_dev_major)
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/version.hpp 
> 090fcf09dd96538a8748cf4443d150911e2c0d27 
> 
> Diff: https://reviews.apache.org/r/32550/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

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

[Benjamin Hindman]

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



3rdparty/libprocess/include/process/http.hpp
<https://reviews.apache.org/r/30032/#comment126239>

How about we take a Time instead of a std::string so that nobody has to 
format the HTTP Last-Modified date string themselves.



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment114629>

Alphabetical ordering please.



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126241>

s/ &path/& path/

Please move '{' to newline.

We use camelCase instead of snake_case for our function names.



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126243>

Two newlines in between functions please.



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126245>

s/static// <-- We'll replace with constexpr later, let's not allocate in 
static storage.



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126246>

if (strftime(...) == 0) {
 ...
}



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126247>

In preference order:

(1) return buffer;
(2) return string(buffer);
(3) return Result(buffer);
(4) return Result(string(buffer));

And please add TODOs in result.hpp if (1) does not compile!



3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/30032/#comment126244>

Result time = Path(response.path).mtime();


- Benjamin Hindman


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

Re: Review Request 26147: Remove non-variadic strings::format() implementation

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On March 25, 2015, 8:02 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26147/
> ---
> 
> (Updated March 25, 2015, 8:02 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Dominic Hamon, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-2549
> https://issues.apache.org/jira/browse/MESOS-2549
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Variadic templates are supported by all our compilers and are already
> relied on by stout (, ).
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/format.hpp 
> 58ab7424c9645fd04d6aea2e4ff56c1ff9815953 
> 
> Diff: https://reviews.apache.org/r/26147/diff/
> 
> 
> Testing
> ---
> 
> Make distcheck ubuntu 14.04
> 
> Compiled with gcc 4.4
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 31930: Introduced an http::Pipe abstraction to simplify streaming HTTP Responses.

[Benjamin Hindman]

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



3rdparty/libprocess/include/process/http.hpp
<https://reviews.apache.org/r/31930/#comment123821>

s/streaming HTTP data/sending an HTTP response via the chunked transfer 
encoding/



3rdparty/libprocess/include/process/http.hpp
<https://reviews.apache.org/r/31930/#comment123817>

Also explain that this is an in-memory single OS process pipe, and is not 
backed by file descriptors so can't be used across a fork.



3rdparty/libprocess/include/process/http.hpp
<https://reviews.apache.org/r/31930/#comment123747>

... Also ignores empty strings as they signify EOF. Which I think is 
dangerous ultimately ... see Joris review.



3rdparty/libprocess/src/tests/http_tests.cpp
<https://reviews.apache.org/r/31930/#comment123819>

Let's still keep this as /pipe for now! ;-) Here and below in this test.


- Benjamin Hindman


On March 11, 2015, 7:41 a.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31930/
> ---
> 
> (Updated March 11, 2015, 7:41 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Jie Yu.
> 
> 
> Bugs: MESOS-2438
> https://issues.apache.org/jira/browse/MESOS-2438
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See MESOS-2438 for the motivation.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/http.hpp 
> 10143fdbd5eb43f968c41957a2335f96a097d82e 
>   3rdparty/libprocess/src/http.cpp 7c0cee404645e1dd1a9253f85883aefa29a5f999 
>   3rdparty/libprocess/src/process.cpp 
> e7b029ba97e640c2102548c190ba62b30602f43d 
>   3rdparty/libprocess/src/tests/http_tests.cpp 
> 800752a57230d7768d3d741fef87f6283757e424 
> 
> Diff: https://reviews.apache.org/r/31930/diff/
> 
> 
> Testing
> ---
> 
> * added tests
> * make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Re: Review Request 31992: Added a TODO for readability reviews.

[Benjamin Hindman]

> On March 12, 2015, 6:53 p.m., Ben Mahler wrote:
> > * Braces: placed on separate line for class / struct / function 
> > definitions. Same line otherwise.
> > 
> > Do we want to tackle higher level style here that is currently missing from 
> > the style guide?
> > 
> > * Use Try / Result to describe functions that can fail synchronously 
> > (rather than returning NULL, -1, etc).
> > * Use Option to capture something that is optionally set (rather than NULL, 
> > -1, etc).
> > * Use Future failure to capture asychronous failures.
> > * Do not block inside the execution context of a libprocess Process.

Yes, I love all these and we should continue to add to the TODO document.


- Benjamin


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


On March 12, 2015, 3:59 p.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31992/
> ---
> 
> (Updated March 12, 2015, 3:59 p.m.)
> 
> 
> Review request for mesos, Bernd Mathiske and Ben Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   readability/TODO PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/31992/diff/
> 
> 
> Testing
> ---
> 
> N/A
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Re: Review Request 31993: Corrected constant naming rule in the style guide.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On March 12, 2015, 4:11 p.m., Alexander Rukletsov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31993/
> ---
> 
> (Updated March 12, 2015, 4:11 p.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   docs/mesos-c++-style-guide.md b24fe4b64a2577060f66ef49ae8b5d4a9d94167c 
> 
> Diff: https://reviews.apache.org/r/31993/diff/
> 
> 
> Testing
> ---
> 
> None (not a functional change).
> 
> 
> Thanks,
> 
> Alexander Rukletsov
> 
>

Review Request 31992: Added a TODO for readability reviews.

[Benjamin Hindman]

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

Review request for mesos, Bernd Mathiske and Ben Mahler.


Repository: mesos


Description
---

See summary.


Diffs
-

  readability/TODO PRE-CREATION 

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


Testing
---

N/A


Thanks,

Benjamin Hindman

Review Request 31990: Added initial readability code review/comments.

[Benjamin Hindman]

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

Review request for mesos, Bernd Mathiske and Ben Mahler.


Repository: mesos


Description
---

The plan is to have a collection of code snippets that capture our unique style 
so that new committers can do "review exercises" to practice and perfect their 
readability requirements. This is just the beginning, we plan on creating a lot 
more of these.


Diffs
-

  readability/naming_comments.cpp PRE-CREATION 
  readability/naming_review.cpp PRE-CREATION 

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


Testing
---

None yet, Bernd is going to handle this for me! Thanks Bernd. ;-)


Thanks,

Benjamin Hindman

Re: Review Request 30774: Fetcher Cache

[Benjamin Hindman]

Path to start?



src/slave/slave.cpp
<https://reviews.apache.org/r/30774/#comment123202>

We should do recovery on the fetcher itself:

Try recover = fetcher->recover(flags, slaveId);

It seems very weird to have a static generic Fetcher recover functionality 
that implies that we can't have multiple Fetchers running at the same time. How 
do we start multiple slaves at the same time?


- Benjamin Hindman


On March 7, 2015, 3:21 p.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30774/
> ---
> 
> (Updated March 7, 2015, 3:21 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESOS-2057, MESOS-2069, MESOS-2070, MESOS-2072, MESOS-2073, and 
> MESOS-2074
> https://issues.apache.org/jira/browse/MESOS-2057
> https://issues.apache.org/jira/browse/MESOS-2069
> https://issues.apache.org/jira/browse/MESOS-2070
> https://issues.apache.org/jira/browse/MESOS-2072
> https://issues.apache.org/jira/browse/MESOS-2073
> https://issues.apache.org/jira/browse/MESOS-2074
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Almost all of the functionality in epic MESOS-336. Downloaded files from 
> CommandInfo::URIs can now be cached in a cache directory designated by a 
> slave flag. This only happens when asked for by an extra flag in the URI and 
> is thus backwards-compatible. The cache has a size limit also given by a new 
> slave flag. Cache-resident files are evicted as necessary to make space for 
> newly fetched ones. Concurrent attempts to cache the same URI leads to only 
> one download. The fetcher program remains external for safety reasons, but is 
> now augmented with more elaborate parameters packed into a JSON object to 
> implement specific fetch actions for all of the above. Additional testing 
> includes fetching from (mock) HDFS and coverage of the new features.
> 
> 
> Diffs
> -
> 
>   docs/fetcher-cache-internals.md PRE-CREATION 
>   docs/fetcher.md PRE-CREATION 
>   include/mesos/fetcher/fetcher.proto 
> 311af9aebc6a85dadba9dbeffcf7036b70896bcc 
>   include/mesos/mesos.proto 9df972d750ce1e4a81d2e96cc508d6f83cad2fc8 
>   src/Makefile.am d299f07d865080676ca8a550cf6005c6ab32839f 
>   src/hdfs/hdfs.hpp 968545d9af896f3e72e156484cc58135405cef6b 
>   src/launcher/fetcher.cpp 796526f59c25898ef6db2b828b0e2bb7b172ba25 
>   src/slave/constants.hpp fd1c1aba0aa62372ab399bee5709ce81b8e92cec 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp 5f4b4ce49a9523e4743e5c79da4050e6f9e29ed7 
>   src/slave/containerizer/fetcher.hpp 
> 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
>   src/slave/containerizer/fetcher.cpp 
> 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 
>   src/slave/containerizer/mesos/containerizer.hpp 
> ae61a0fcd19f2ba808624312401f020121baf5d4 
>   src/slave/containerizer/mesos/containerizer.cpp 
> ec4626f903d44c0911093ff763ef16ad27c418a9 
>   src/slave/flags.hpp 56b25caf3901b38bdecb50310e8bcae0b114efa8 
>   src/slave/slave.cpp a06d68032f26ccb3f786b6ea7c3a6c3c52449bd2 
>   src/tests/docker_containerizer_tests.cpp 
> 06cd3d89ecbaaac17ae6970604b21fbe29f6e887 
>   src/tests/fetcher_cache_tests.cpp PRE-CREATION 
>   src/tests/fetcher_tests.cpp 4549e6a631e2c17cec3766efaa556593eeac9a1e 
>   src/tests/mesos.hpp e91e5e484eea4587ac8f2eb9cefeab4acc9f4615 
>   src/tests/mesos.cpp c8f43d21b214e75eaac2870cbdf4f03fd18707d1 
> 
> Diff: https://reviews.apache.org/r/30774/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> --- longer Description: ---
> 
> -Replaces all other reviews for the fetcher cache except those related to 
> stout: 30006, 30033, 30034, 30036, 30037, 30039, 30124, 30173, 30614, 30616, 
> 30618, 30621, 30626. See descriptions of those. In dependency order:
> 
> 30033: Removes the fetcher env tests since these won't be needed any more 
> when the fetcher uses JSON in a single env var as a parameter. They never 
> tested anything that won't be covered by other tests anyway.
> 
> 30034: Makes the code structure of all fetcher tests the same. Instead of 
> calling the run method of the fetcher directly, calling through fetch(). Also 
> removes all uses of I/O redirection, which is not really needed for 
> debugging, and thus the next patch can refactor fetch() and run(). (The 
> latter comes in two varieties, which complicates matters without much 
> benefit.)
> 
> 30036: Extends the CommandInfo::URI protobuf with a boolean "

Review Request 31614: Added a comment about uses of FetcherProcess::cache withotu 'defer'.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

There are race conditions where if a FetcherProcess is being shutdown but there 
are still outstanding asynchronous calls that use things like 
FetcherProcess::cache that memory will actually get deleted and we'll segfault. 
This patch addresses one of those cases.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31613: Added a comment to help suss out potential bug.

[Benjamin Hindman]

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

Review request for mesos.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31613: Added a comment to help suss out potential bug.

[Benjamin Hindman]

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

(Updated March 2, 2015, 6:20 a.m.)


Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31612: Release a failed cache entry's space properly.

[Benjamin Hindman]

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

(Updated March 2, 2015, 6:19 a.m.)


Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

The flow of a failed cache entry is very difficult to follow, this attempts to 
simplify and at least adds more comments.


Diffs (updated)
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31612: Release a failed cache entry's space properly.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

The flow of a failed cache entry is very difficult to follow, this attempts to 
simplify and at least adds more comments.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31610: Simplified 'cleanupCache' by adjusting cache sizes earlier.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

Rather than waiting to asynchronously adjust the claimed cache space in 
'cleanupCache' which seemed to be a very important part of the "success" flow 
of the algorithm this was moved earlier (right to where success occurs, in 
FetcherProcess::___fetch). This enabled making FetcherProcess::cleanupCache be 
more focused on cleaning up new cache entries when mesos-fetcher fails.


Diffs
-

  src/slave/containerizer/fetcher.hpp 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31611: Store the cache directory within each Cache::Entry.

[Benjamin Hindman]

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

Review request for mesos.


Repository: mesos


Description
---

This simplifies many of the function calls, lambda::binds, and function bodies 
by removing distracting code.


Diffs
-

  src/slave/containerizer/fetcher.hpp 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31609: Simplifying FetcherProcess::cleanupCache.

[Benjamin Hindman]

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

(Updated March 2, 2015, 5:48 a.m.)


Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.hpp 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31603: Cleaned up a few style issues.

[Benjamin Hindman]

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

(Updated March 2, 2015, 5:48 a.m.)


Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31609: Simplifying FetcherProcess::cleanupCache.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.hpp 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31603: Cleaned up a few style issues.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31602: Changes necessary for building with gcc 4.4.

[Benjamin Hindman]

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

Review request for mesos and Bernd Mathiske.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/slave/containerizer/fetcher.hpp 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
  src/slave/containerizer/fetcher.cpp 9e9e9d0eb6b0801d53dec3baea32a4cd4acdd5e2 
  src/tests/fetcher_cache_tests.cpp PRE-CREATION 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Scaling Proposal: MAINTAINERS Files

[Benjamin Hindman]

I had chatted with BenM and Vinod pretty extensively about this and am a +1.

BenM: can you confirm how this interacts with the Apache by-laws?

On Sat, Feb 14, 2015 at 10:25 AM, Till Toenshoff  wrote:

> +1 — thanks for this Ben!
>
> > On Feb 10, 2015, at 8:56 PM, Cody Maloney  wrote:
> >
> > +1
> >
> > It would be nice if there was way to specify things like "build system
> > changes" which are different than just adding/removing a single file. But
> > probably that level of enforcement isn't worth the effort it would take
> to
> > add.
> >
> > On Tue, Feb 10, 2015 at 8:56 AM, James DeFelice <
> james.defel...@gmail.com>
> > wrote:
> >
> >> +1 Tom/Adam
> >>
> >> --sent from my phone
> >> On Feb 10, 2015 10:52 AM, "Niklas Nielsen" 
> wrote:
> >>
> >>> +1
> >>> Thanks for the write up Ben!
> >>>
> >>> On Tuesday, February 10, 2015, Dominic Hamon
>  >>>
> >>> wrote:
> >>>
>  Well, we should probably do that anyway :)
>  On Feb 10, 2015 2:25 AM, "Adam Bordelon"   > wrote:
> 
> > +1 on MAINTAINERS over OWNERS, and the rest of the proposal thus far.
> > Also +1 on "Merit is not about quantity of work, it means doing
> >> things
>  the
> > community values in a way that the community values."
> > I will, however, echo Tom's concern that we may need to break up
>  master.cpp
> > and slave.cpp if we want fine-grained maintainers of subcomponents of
> > either.
> >
> > On Mon, Feb 9, 2015 at 1:47 PM, Yan Xu >
>  wrote:
> >
> >> Good point for "MAINTAINERS"
> >>
> >> --
> >> Jiang Yan Xu > @xujyan <
>  http://twitter.com/xujyan>
> >>
> >> On Mon, Feb 9, 2015 at 12:05 PM, Vinod Kone   > wrote:
> >>
> >>> I like MAINTAINERS because it sounds less authoritative than
> >>> OWNERS.
> >>>
> >>> FWIW, maintainers is also a well understood and well used term
> >>> (e.g:
> >>> https://www.kernel.org/doc/linux/MAINTAINERS,
> >>>
> >>>
> >>
> >
> 
> >>>
> >>
> https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-AddingMaintainerInformation
> >>> )
> >>>
> >>> On Sun, Feb 8, 2015 at 10:40 AM, Dominic Hamon <
> > dha...@twopensource.com >
> >>> wrote:
> >>>
>  Yes, great.
> 
>  Why not use OWNERS as it is already in use internally at
> >> Twitter,
>  at
>  Google, in Chromium, and tooling already supports that as an
>  implicit
>  standard?
>  On Feb 8, 2015 2:52 AM, "Benjamin Mahler" <
>  benjamin.mah...@gmail.com 
> >>
>  wrote:
> 
> > Hi all,
> >
> > I have been chatting with a few committers and we'd like to
> > consider
>  adding
> > the concept of MAINTAINERS files to coincide with our
> >>> "shepherds"
>  concept,
> > introduced here:
> >
> >
> >
> 
> >>>
> >>
> >
> 
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3ccafeoqnwjibkayurkf0mfxve2usd5d91xpoe8u+pktiyvszv...@mail.gmail.com%3E
> >
> > Please take a moment to read that thread and its responses
> >> here
>  in
> >>> which
> > maintainers are alluded to:
> >
> >
> >
> 
> >>>
> >>
> >
> 
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3cca+a2mtvc61-3idxtm-ghgcxekqxwz063ouhpbrgbpvsa9zs...@mail.gmail.com%3E
> >
> >
> >
> 
> >>>
> >>
> >
> 
> >>>
> >>
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201404.mbox/%3CCAAkWvAxegdg8+QQ4-sqZ-SKi9J=2WJDCVg_Sc9aaHttS4=6...@mail.gmail.com%3E
> >
> > *Motivation:*
> >
> > To re-iterate from that thread, many companies rely on Mesos
> >> as
>  the
> > foundational layer of their software infrastructure stack.
> >> Much
>  of
> >> the
> > success of Mesos can be attributed to our focus on quality
> >>> (code
> > that
> >>> is
> > simple / easy to read and understand, high attention to
> >> detail,
> >>> thorough
> > reviewing, good testing practices, managing technical debt,
> > learning
> >>> from
> > each other, etc).
> >
> > As the community of contributors has grown, it's become
> > increasingly
> > difficult to ensure that people are able to find reviewers
> >> with
>  experience
> > in specific areas of the project. Good contributions often
> >> fall
> >> through
>  the
> > cracks as a result of the lack of clarity around this.
> >
> > We would like to ensure that reviewers with context and a
>  long-term
>  outlook
> > on the particular area of the code are involved in providing
> >> feedback.
> >>> It
> > can be difficult for a contributor to consider the
> >

Re: Review Request 31236: Re-introduce "internal" namespace for src/*.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Feb. 22, 2015, 9:39 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31236/
> ---
> 
> (Updated Feb. 22, 2015, 9:39 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-2371
> https://issues.apache.org/jira/browse/MESOS-2371
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Reverted 30295 and 30300.
> 
> 
> Diffs
> -
> 
>   include/mesos/executor.hpp cf82b04f9c3f7930fe4fdf74c13d3ffd2009bffe 
>   include/mesos/scheduler.hpp 31256c1c471232b5d879290e1b8ad914d26cf7a0 
>   include/mesos/values.hpp e9576779dad84c1783cfa4c8864d94d7135946dc 
>   src/authentication/cram_md5/authenticatee.hpp 
> 33119160cea0bdf41a820c61c6fcbef7766d7ba3 
>   src/authentication/cram_md5/authenticator.hpp 
> 7578ea160903206628672f5ed84b6032c9a38c0a 
>   src/authentication/cram_md5/auxprop.hpp 
> d036b111711affae6e49a74f30ca769346765e58 
>   src/authentication/cram_md5/auxprop.cpp 
> 5ff9755814f439712652b336fd51d64cea2cf433 
>   src/authorizer/authorizer.hpp 66ddb922511aee34063f9efe8371d3fc31af150f 
>   src/authorizer/authorizer.cpp 4f2b6a788df00ad9236f346c6b7e123ccfbe57f6 
>   src/cli/execute.cpp c55e961e60a106acaca35cd75b290990d75f804c 
>   src/cli/resolve.cpp 77bd4439f696bf16407a84243980834080af8f88 
>   src/common/attributes.hpp 844bdbfe7df14ff7b9912697937c18e7e57f482d 
>   src/common/attributes.cpp 33da50ca535756f99bc6689b26fe617d121975cc 
>   src/common/build.hpp 9765c8f3843b1da61db778fde1ddc075a5f99e63 
>   src/common/build.cpp 90bd7192ac266e21f24eadf08945adeaa85b0f84 
>   src/common/date_utils.hpp b11c8e093d993ee69859437a75976566e7119acc 
>   src/common/date_utils.cpp a148fd8763ea64593dc08380cf65e32c7ee96c7f 
>   src/common/factory.hpp 26f545b0edecd6a95dd18f799900940fb02d45ba 
>   src/common/http.hpp bdb5948a850ac9dda066dcb895c092d2108f62a5 
>   src/common/http.cpp 4b6040837a1532b3264a1a3a38b618841cc19961 
>   src/common/lock.hpp fbe04e0e8b0adc925bbb808c5fb299085cc69b36 
>   src/common/lock.cpp a52d3ff917cbb624f072e9dec4c4da656028f1fe 
>   src/common/protobuf_utils.hpp 82c6e4f693fe3e02d76d2865702d79f28c3e19b5 
>   src/common/protobuf_utils.cpp c398c58511d74c33f24002f79c01fcd45842df36 
>   src/common/resources.cpp 98371f6873482d0cdbefeb279b58ae6cc680a88f 
>   src/common/type_utils.cpp 12a36bbd7d7773b25dedf2d0d951c79e0b5141d6 
>   src/common/values.cpp 242f2a090d5d654d7efba2129eb7b7b7cd390029 
>   src/credentials/credentials.hpp 130beed342b508049fa02655ff72ba3467eb386e 
>   src/docker/docker.cpp 94f16e701f89367b599f0bd8f44c2f1de21a8e20 
>   src/examples/balloon_framework.cpp 08bb613e8296cfbe4fca98fa9856c2892653eb1f 
>   src/examples/load_generator_framework.cpp 
> 16d278278df9eac5ee18d853f10c918751dbebf7 
>   src/examples/low_level_scheduler_libprocess.cpp 
> 986b175e86e153c315d0bea03f602d3855352d3e 
>   src/examples/low_level_scheduler_pthread.cpp 
> d69e68b9f6d768ebb7961ee53f10d74574195606 
>   src/examples/test_authentication_modules.cpp 
> 5ff58d2f824cb527ca6faa906aec96cbb5159d8c 
>   src/examples/test_framework.cpp 0a4fde50cc533f54a5dbeb2899cbe3eeb6f133cb 
>   src/examples/test_isolator_module.cpp 
> a66dc74de24d117dbcf9a3063bf5e2f69dbb1138 
>   src/exec/exec.cpp 8250bd4ec9028fb4667b9c703a2bb780fbf2171e 
>   src/files/files.hpp c8322d1381b6ba0e52bd29a4291fd3a786ce5fe0 
>   src/files/files.cpp 58a74b10af65ee30b7035ff00725d0f8e98529ea 
>   src/health-check/main.cpp 260b872272955f7ee20c0cc1d53d578d7ad2b731 
>   src/hook/manager.hpp a6594c180e772beccaf5beeaafc5cc02f69621a4 
>   src/hook/manager.cpp a6938d09851898dd5853d86231c9f9d9db15729b 
>   src/java/jni/org_apache_mesos_Log.cpp 
> 3261b616eac6b785a80f828036b1b3859a93e4ff 
>   src/java/jni/org_apache_mesos_state_AbstractState.cpp 
> d7e6cb5fcb39981471f00a90b4107e4059aadd93 
>   src/java/jni/org_apache_mesos_state_LevelDBState.cpp 
> 27e8905bd1804922b9c64e4ababb7ea98d8c4103 
>   src/java/jni/org_apache_mesos_state_LogState.cpp 
> dc1e49dcc722bc518159b61ca9f4869410589418 
>   src/java/jni/org_apache_mesos_state_Variable.cpp 
> b600996ac6872970516e22447db0157c64140214 
>   src/java/jni/org_apache_mesos_state_ZooKeeperState.cpp 
> 7b81760b3e7f9c6a6a4bc6e0bddf50c688a32b8e 
>   src/jvm/jvm.cpp 38fedfcab0a415ad57f8c4ae6b92e3cac0900a2b 
>   src/laun

Re: Review Request 31279: Enclosed tests in "mesos::internal::tests" namespace.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Feb. 22, 2015, 9:39 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31279/
> ---
> 
> (Updated Feb. 22, 2015, 9:39 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-2371
> https://issues.apache.org/jira/browse/MESOS-2371
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Enclosed tests in "mesos::internal::tests" namespace or 
> "mesos::internal::slave" namespace as needed.
> 
> The idea was to avoid doing a "using namespace mesos::internal::slave;" or 
> similar things.
> 
> 
> Diffs
> -
> 
>   src/tests/attributes_tests.cpp 138d543e64ed74367e849dd42453d38336519796 
>   src/tests/authentication_tests.cpp 59d29549b2831a0a50478456d16fdc41022a221e 
>   src/tests/authorization_tests.cpp edae66d3de91d8a8eb3ed8fc940309a0e9f593f6 
>   src/tests/cgroups_isolator_tests.cpp 
> 9fbde334f596f3673bb84657731c161ac6578c42 
>   src/tests/cgroups_tests.cpp 9d50a47c939f5f136c85fdcc555459512c6f2259 
>   src/tests/composing_containerizer_tests.cpp 
> 6bb49ea780b0fe79974e57b35f886ee82a1e3f1c 
>   src/tests/containerizer_tests.cpp 06788493c263e623644f8d4df8cca44a74800ebb 
>   src/tests/credentials_tests.cpp 4210d315bae423cf27d181a633090c99d2f5bc62 
>   src/tests/disk_quota_tests.cpp 1d3aa0c395ddcd59a5072a5a47b3cf8ed05567ed 
>   src/tests/docker_containerizer_tests.cpp 
> 8b212d4e6ed5a179ebadce1bdbbf3edde87d706c 
>   src/tests/docker_tests.cpp ae01a4e6fcd36cd6747d9c77d339403ebbb5c78a 
>   src/tests/exception_tests.cpp 7a41770c26519541fed10672e13ee833a2d6dd5e 
>   src/tests/external_containerizer_test.cpp 
> d6c4437d8a9b4b46740c3a3a626908cd69081541 
>   src/tests/fault_tolerance_tests.cpp 
> efa5c57d98308e9d54723d361533b39b99551261 
>   src/tests/fetcher_tests.cpp fcbf7ad912f0b1b3d106a75a9dcb8213a0c69c07 
>   src/tests/files_tests.cpp 650f1b947d87b7e17651f7378369d3ade826e412 
>   src/tests/fs_tests.cpp 0ea286b21788b8c32a2e961514f45d713decd77d 
>   src/tests/gc_tests.cpp c74287a29eaa8478c301ef3bcfd9af1e27a67b7e 
>   src/tests/group_tests.cpp 5344087ffb6a8313e046906b6e3b40fc3bc13d98 
>   src/tests/health_check_tests.cpp 7fcb2310e9e9d203b78925315ff71d3f7396f099 
>   src/tests/hierarchical_allocator_tests.cpp 
> eeecfb64540b1915074aaffaa5d506b203bc 
>   src/tests/hook_tests.cpp dc6d289394e5718a37936e29ad6d988b52933f98 
>   src/tests/isolator.hpp 5ad338b031fd5e69ebad6cb861d4d33062cd492e 
>   src/tests/isolator_tests.cpp ab4bacc19f84ec9cba4576c95b43425ba352fd67 
>   src/tests/log_tests.cpp 8cbc4df5dac49eef4ab618f47862812266ed513d 
>   src/tests/logging_tests.cpp 0f2d30dcc048a8098b66bf65cb065917438542d3 
>   src/tests/master_allocator_tests.cpp 
> df9ac24280514932dc118408b11adc806f548f5e 
>   src/tests/master_authorization_tests.cpp 
> fadbd38f50c9587a9b1755d96a96e10c540264c5 
>   src/tests/master_contender_detector_tests.cpp 
> 78b1a6a393a0c69ade12d7f74ee931254b9975db 
>   src/tests/master_slave_reconciliation_tests.cpp 
> 5156898a4ec02a2ad0080ab768e360077f0ba0f1 
>   src/tests/master_tests.cpp 3a9da68364fda25ac25565a1d2799f2dfaf736da 
>   src/tests/master_validation_tests.cpp 
> e2b64267cb0df5c9944f27d01af90ae15a1f2432 
>   src/tests/metrics_tests.cpp 3b2dc24b41293a5c539bfd0a0248d9c25fe654d5 
>   src/tests/module.cpp 3c9bab7a192a63adfa3cfc8fd1e29dada00f8095 
>   src/tests/module_tests.cpp a16ba994951ef581d703e96b14f4d95f483cb2cf 
>   src/tests/monitor_tests.cpp b640d89c8c91a83dce3ff08e65b8efaf493a419e 
>   src/tests/ns_tests.cpp b11a216b180103311fab462d7c460a5326d51575 
>   src/tests/partition_tests.cpp eb16a58c23e0c152212140841ed09cd7f6f139d6 
>   src/tests/perf_tests.cpp 55a2daeb581945300d2fa55f3d30d9fbcef56b0e 
>   src/tests/persistent_volume_tests.cpp 
> b4f2298069233b27f6b4b8d668753810f43bb58d 
>   src/tests/port_mapping_tests.cpp 308f629bc02d7bb4bbae385a0c816b567594f679 
>   src/tests/protobuf_io_tests.cpp 92a090a221bcbdc7adc4ca3c717302c48c57902d 
>   src/tests/rate_limiting_tests.cpp 784ac76ee81918466de44196f5adc2b88adfee96 
>   src/tests/reconciliation_tests.cpp 4c97341a1e84b1504090e8b3fdd8b309abf65877 
>   src/tests/registrar_tests.cpp fd312930e33e332c3d5b6291c191050378694d9e 
>   src/tests/registrar_zookeeper_tests.cpp 
> 7c9aa816bd2a3be00a4b339c71886bb8abbe97d6 

Re: Review Request 31288: Fixed bug in tests from 'internal' revert.

[Benjamin Hindman]

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

(Updated Feb. 22, 2015, 11:57 p.m.)


Review request for mesos, Kapil Arya and Niklas Nielsen.


Repository: mesos


Description
---

I'm not sure how the tests were ever passing?


Diffs
-

  src/tests/rate_limiting_tests.cpp 784ac76ee81918466de44196f5adc2b88adfee96 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31287: Removed unnecessary 'mesos::' qualifier.

[Benjamin Hindman]

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

(Updated Feb. 22, 2015, 11:57 p.m.)


Review request for mesos, Kapil Arya and Niklas Nielsen.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/module/manager.hpp f071678aca0729c14147b16f00a6f1e0daf9094e 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31288: Fixed bug in tests from 'internal' revert.

[Benjamin Hindman]

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

Review request for mesos, Kapil Arya and Niklas Nielsen.


Repository: mesos


Description
---

I'm not sure how the tests were ever passing?


Diffs
-

  src/tests/rate_limiting_tests.cpp 784ac76ee81918466de44196f5adc2b88adfee96 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31287: Removed unnecessary 'mesos::' qualifier.

[Benjamin Hindman]

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

Review request for mesos, Kapil Arya and Niklas Nielsen.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/module/manager.hpp f071678aca0729c14147b16f00a6f1e0daf9094e 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31286: Removed all 'namespace slave {' and 'namespace master {' from tests.

[Benjamin Hindman]

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

(Updated Feb. 22, 2015, 10:55 p.m.)


Review request for mesos and Kapil Arya.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/tests/containerizer_tests.cpp 06788493c263e623644f8d4df8cca44a74800ebb 
  src/tests/rate_limiting_tests.cpp 784ac76ee81918466de44196f5adc2b88adfee96 
  src/tests/registrar_tests.cpp fd312930e33e332c3d5b6291c191050378694d9e 
  src/tests/slave_recovery_tests.cpp 24c28af7ff0425920cb5c0bf430e21962de2b12d 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Review Request 31286: Removed all 'namespace slave {' and 'namespace master {' from tests.

[Benjamin Hindman]

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

Review request for mesos and Kapil Arya.


Repository: mesos


Description
---

See summary.


Diffs
-

  src/tests/containerizer_tests.cpp 06788493c263e623644f8d4df8cca44a74800ebb 
  src/tests/rate_limiting_tests.cpp 784ac76ee81918466de44196f5adc2b88adfee96 
  src/tests/registrar_tests.cpp fd312930e33e332c3d5b6291c191050378694d9e 
  src/tests/slave_recovery_tests.cpp 24c28af7ff0425920cb5c0bf430e21962de2b12d 

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


Testing
---

make check


Thanks,

Benjamin Hindman

Re: Review Request 31236: Re-introduce "internal" namespace for src/*.

[Benjamin Hindman]

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



src/common/factory.hpp
<https://reviews.apache.org/r/31236/#comment119800>

Was this in the code pre-30295 that way?


- Benjamin Hindman


On Feb. 22, 2015, 9:39 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31236/
> ---
> 
> (Updated Feb. 22, 2015, 9:39 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas 
> Nielsen, and Vinod Kone.
> 
> 
> Bugs: MESOS-2371
> https://issues.apache.org/jira/browse/MESOS-2371
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Reverted 30295 and 30300.
> 
> 
> Diffs
> -
> 
>   include/mesos/executor.hpp cf82b04f9c3f7930fe4fdf74c13d3ffd2009bffe 
>   include/mesos/scheduler.hpp 31256c1c471232b5d879290e1b8ad914d26cf7a0 
>   include/mesos/values.hpp e9576779dad84c1783cfa4c8864d94d7135946dc 
>   src/authentication/cram_md5/authenticatee.hpp 
> 33119160cea0bdf41a820c61c6fcbef7766d7ba3 
>   src/authentication/cram_md5/authenticator.hpp 
> 7578ea160903206628672f5ed84b6032c9a38c0a 
>   src/authentication/cram_md5/auxprop.hpp 
> d036b111711affae6e49a74f30ca769346765e58 
>   src/authentication/cram_md5/auxprop.cpp 
> 5ff9755814f439712652b336fd51d64cea2cf433 
>   src/authorizer/authorizer.hpp 66ddb922511aee34063f9efe8371d3fc31af150f 
>   src/authorizer/authorizer.cpp 4f2b6a788df00ad9236f346c6b7e123ccfbe57f6 
>   src/cli/execute.cpp c55e961e60a106acaca35cd75b290990d75f804c 
>   src/cli/resolve.cpp 77bd4439f696bf16407a84243980834080af8f88 
>   src/common/attributes.hpp 844bdbfe7df14ff7b9912697937c18e7e57f482d 
>   src/common/attributes.cpp 33da50ca535756f99bc6689b26fe617d121975cc 
>   src/common/build.hpp 9765c8f3843b1da61db778fde1ddc075a5f99e63 
>   src/common/build.cpp 90bd7192ac266e21f24eadf08945adeaa85b0f84 
>   src/common/date_utils.hpp b11c8e093d993ee69859437a75976566e7119acc 
>   src/common/date_utils.cpp a148fd8763ea64593dc08380cf65e32c7ee96c7f 
>   src/common/factory.hpp 26f545b0edecd6a95dd18f799900940fb02d45ba 
>   src/common/http.hpp bdb5948a850ac9dda066dcb895c092d2108f62a5 
>   src/common/http.cpp 4b6040837a1532b3264a1a3a38b618841cc19961 
>   src/common/lock.hpp fbe04e0e8b0adc925bbb808c5fb299085cc69b36 
>   src/common/lock.cpp a52d3ff917cbb624f072e9dec4c4da656028f1fe 
>   src/common/protobuf_utils.hpp 82c6e4f693fe3e02d76d2865702d79f28c3e19b5 
>   src/common/protobuf_utils.cpp c398c58511d74c33f24002f79c01fcd45842df36 
>   src/common/resources.cpp 98371f6873482d0cdbefeb279b58ae6cc680a88f 
>   src/common/type_utils.cpp 12a36bbd7d7773b25dedf2d0d951c79e0b5141d6 
>   src/common/values.cpp 242f2a090d5d654d7efba2129eb7b7b7cd390029 
>   src/credentials/credentials.hpp 130beed342b508049fa02655ff72ba3467eb386e 
>   src/docker/docker.cpp 94f16e701f89367b599f0bd8f44c2f1de21a8e20 
>   src/examples/balloon_framework.cpp 08bb613e8296cfbe4fca98fa9856c2892653eb1f 
>   src/examples/load_generator_framework.cpp 
> 16d278278df9eac5ee18d853f10c918751dbebf7 
>   src/examples/low_level_scheduler_libprocess.cpp 
> 986b175e86e153c315d0bea03f602d3855352d3e 
>   src/examples/low_level_scheduler_pthread.cpp 
> d69e68b9f6d768ebb7961ee53f10d74574195606 
>   src/examples/test_authentication_modules.cpp 
> 5ff58d2f824cb527ca6faa906aec96cbb5159d8c 
>   src/examples/test_framework.cpp 0a4fde50cc533f54a5dbeb2899cbe3eeb6f133cb 
>   src/examples/test_isolator_module.cpp 
> a66dc74de24d117dbcf9a3063bf5e2f69dbb1138 
>   src/exec/exec.cpp 8250bd4ec9028fb4667b9c703a2bb780fbf2171e 
>   src/files/files.hpp c8322d1381b6ba0e52bd29a4291fd3a786ce5fe0 
>   src/files/files.cpp 58a74b10af65ee30b7035ff00725d0f8e98529ea 
>   src/health-check/main.cpp 260b872272955f7ee20c0cc1d53d578d7ad2b731 
>   src/hook/manager.hpp a6594c180e772beccaf5beeaafc5cc02f69621a4 
>   src/hook/manager.cpp a6938d09851898dd5853d86231c9f9d9db15729b 
>   src/java/jni/org_apache_mesos_Log.cpp 
> 3261b616eac6b785a80f828036b1b3859a93e4ff 
>   src/java/jni/org_apache_mesos_state_AbstractState.cpp 
> d7e6cb5fcb39981471f00a90b4107e4059aadd93 
>   src/java/jni/org_apache_mesos_state_LevelDBState.cpp 
> 27e8905bd1804922b9c64e4ababb7ea98d8c4103 
>   src/java/jni/org_apache_mesos_state_LogState.cpp 
> dc1e49dcc722bc518159b61ca9f4869410589418 
>   src/java/jni/org_apache_mesos_state_Variable.cpp 
> b600996ac6872970516e22447db0157c64140214 
>   src/java/jni/org_apache_mesos_state_ZooKeeperState.

Re: Review Request 31218: MESOS-2377: Fix leak in libevent EventLoop::handle_delay.

[Benjamin Hindman]

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

Ship it!


Did someone come across this bug?

- Benjamin Hindman


On Feb. 20, 2015, 4:31 a.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31218/
> ---
> 
> (Updated Feb. 20, 2015, 4:31 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Bugs: MESOS-2377
> https://issues.apache.org/jira/browse/MESOS-2377
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/libevent.cpp 
> c001054dce35d65b7ea779d77963194c78af3a84 
> 
> Diff: https://reviews.apache.org/r/31218/diff/
> 
> 
> Testing
> ---
> 
> make check.
> valgrind --tool=massif
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Re: Review Request 30971: Introduced explicit status update acknowledgements on the driver.

[Benjamin Hindman]

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

Ship it!



include/mesos/mesos.proto
<https://reviews.apache.org/r/30971/#comment119519>

s/once it/once if it/



include/mesos/scheduler.hpp
<https://reviews.apache.org/r/30971/#comment119522>

Any reason not to just:

Status acknowledge(const TaskStatus& status) = 0;

Then down below you can do a 'status.has_uuid()'.



include/mesos/scheduler.hpp
<https://reviews.apache.org/r/30971/#comment119520>

Can we put a newline between these please?



src/sched/sched.cpp
<https://reviews.apache.org/r/30971/#comment119521>

s/uuid/UUID/ s/id/ID/ Acronyms!



src/sched/sched.cpp
<https://reviews.apache.org/r/30971/#comment119524>

Rather than 'abort()' we should use ABORT() << "message";


- Benjamin Hindman


On Feb. 18, 2015, 11:43 p.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30971/
> ---
> 
> (Updated Feb. 18, 2015, 11:43 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Vinod Kone.
> 
> 
> Bugs: MESOS-2347
> https://issues.apache.org/jira/browse/MESOS-2347
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Introduced explicit status update acknowledgements on the driver.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 507845c493f65e154214fc7e562206e452990469 
>   include/mesos/scheduler.hpp 31256c1c471232b5d879290e1b8ad914d26cf7a0 
>   src/sched/sched.cpp ea7e447e522f8fa335ee5dbdc6d65d4018042905 
>   src/scheduler/scheduler.cpp 5816569dc9cfeb86fe59b8fbea1518825b403182 
> 
> Diff: https://reviews.apache.org/r/30971/diff/
> 
> 
> Testing
> ---
> 
> Added tests in subsequent reviews.
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Re: Review Request 31162: Backout change 30300 (Move internal protos from mesos::internal to mesos namespace)

[Benjamin Hindman]

> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/tests/state_tests.cpp, lines 86-87
> > 
> >
> > typedef Registry::Slaves Slaves;
> > typedef Registry::Slave Slave;

This reverts the code to it's original state which is most explicit, let's 
leave it as it is.


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/tests/rate_limiting_tests.cpp, line 1058
> > 
> >
> > I would suggest just change this comment to not include the namespace 
> > so that we don't forget to change this once we move forward.
> > ```
> > Message RegisterFrameworkMessage ...
> > ```
> > 
> > Please do a sweep to find all such cases and fix them.

+1


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/messages/messages.hpp, lines 73-107
> > 
> >
> > Curious why these are not in type_utils?

I'm assuming this was not part of Kapil's change, so let's move them later. 
Dropping this issue for now.


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/log/leveldb.cpp, lines 42-43
> > 
> >
> > Ditto above.

This one is in a .cpp file, dropping.


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/log/consensus.hpp, lines 44-47
> > 
> >
> > Let's keep all the namespace hacks in protobuf wrapper headers so that 
> > it's easy for us to find them later. In this case, you can put `using 
> > namespace mesos::internal::log` in messages/log.hpp.

Do we need any "hacks" here? If so, we need to CLEARLY call them out with 
comments. Ideally we don't need any hacks, please point me to any hacks.


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > src/common/type_utils.cpp, lines 160-161
> > 
> >
> > I am wondering why this is necessary if you already included 
> > messages/messages.hpp (which has using namespace mesos::internal)?

Regardless, we shouldn't have the 'using' in the headers, so we should be 
keeping this here IIUC.


> On Feb. 19, 2015, 2:28 a.m., Jie Yu wrote:
> > include/mesos/type_utils.hpp, lines 377-384
> > 
> >
> > Instead of pulling it into module.hpp, can you keep it here? Also, if 
> > you include module/module.hpp, do you still need to change this code?

+1, why the code movement of this?


- Benjamin


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


On Feb. 19, 2015, 12:59 a.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31162/
> ---
> 
> (Updated Feb. 19, 2015, 12:59 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Jie Yu, Niklas Nielsen, Till Toenshoff, 
> and Vinod Kone.
> 
> 
> Bugs: MESOS-2371
> https://issues.apache.org/jira/browse/MESOS-2371
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This changeset puts the internal protos back into mesos::internal namespace.
> This is required for upgrade compatibility.  Without it, a newer Master would
> reject all messages from an older Slave and vice-versa.
> 
> https://reviews.apache.org/r/30300/
> 
> 
> Diffs
> -
> 
>   include/mesos/authentication/authentication.hpp 
> 699aa886286bc7d9c05592e71232ab1c1084871f 
>   include/mesos/authentication/authentication.proto 
> 38a6f781d6a0b4618a14e1681420564d78b840a8 
>   include/mesos/module/module.hpp e83be2822b7c0e7935ab1c8af36e5cb9b5180f20 
>   include/mesos/module/module.proto 821fc0e72ece7c497595859fc5efc1c64ea49b9b 
>   include/mesos/type_utils.hpp cdf5864389a72002b538c263d70bcade2bdffa45 
>   src/common/parse.hpp 547b32041f39f0ff0c38179b66a32b2239134abc 
>   src/common/type_utils.cpp 12a36bbd7d7773b25dedf2d0d951c79e0b5141d6 
>   src/log/consensus.hpp ee9e9081ffe2a5f18433d9eff1a2e2cf17c81863 
>   src/log/leveldb.hpp 8f5df5bdfb08de02e4129494fba188f97c3b8010 
>   src/log/leveldb.cpp 1d679425c6df3498be67d048bc05d02ffe03a636 
>   src/log/replica.hpp b2602083564447cf75827257a2548c1b5aeb49e2 
>   src/log/storage.hpp 5e81f4e9774ad239145019320cf991fcf51a9da5 
>   src/master/registry.hpp d3cbe564dc8e14f3dd301e5bc06ed60d82856eee 
>   src/master/registry.proto 29a309763bca9db76c443d7c039ca152a2afbc5b 
>   src/messages/log.proto 12b3572e0fe0e30c5eff20c7af27eb3d7cfe8f4b 
>   src/messages/messages.hpp 25769b797ec9bd1a1c348c467616aef8407c45d6 
>   src/messages/messages.proto 58484ae45071

Re: Review Request 31145: Fixed a CPU-intensive bug in libprocess' clock.

[Benjamin Hindman]

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

Ship it!



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/31145/#comment119010>

s/'timer's/'timers'/
s/'ticks's/'ticks'/



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/31145/#comment119011>

Just to be so ultra explicit, a brief comment explaining a negative delay 
is okay, it should cause 'tick' to fire immediately.


- Benjamin Hindman


On Feb. 18, 2015, 3:12 a.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31145/
> ---
> 
> (Updated Feb. 18, 2015, 3:12 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-2325
> https://issues.apache.org/jira/browse/MESOS-2325
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This is based on some discussions w/ benh and Joris' patch here:
> https://reviews.apache.org/r/30808/
> 
> The issue is outlined in the ticket. To fix this, we keep track of the 
> scheduled '`ticks`' and only schedule another if it's earlier than the other 
> '`ticks`'.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/clock.cpp b92d5de2631986506361e28c05cb6169e6632a70 
> 
> Diff: https://reviews.apache.org/r/31145/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Re: Review Request 31141: Fixed a clock bug in next().

[Benjamin Hindman]

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

Ship it!



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/31141/#comment119007>

Not your bug but s/'timer's/'timers'/



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/31141/#comment119008>

Can we add another comment here, perhaps after we've calcuated 'duration', 
that explains that it's possible that 'duration' is negative which implies the 
timer should have expired but that this is an accepted result. And maybe even 
add a brief comment for as much in the comment above this function? Thanks Ben, 
I want to leave as many breadcrumbs for the next people that work on this code 
as possible.



3rdparty/libprocess/src/clock.cpp
<https://reviews.apache.org/r/31141/#comment119009>

Please add a comment just above this that explains we're passing NULL to be 
explicit about getting the global clock value, thanks Ben!


- Benjamin Hindman


On Feb. 18, 2015, 3:11 a.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31141/
> ---
> 
> (Updated Feb. 18, 2015, 3:11 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Joris Van Remoortere.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> When the clock is paused, `next()` should return `None()` since no timers can 
> fire until the clock is advanced or updated.
> 
> As a regression during the re-factoring, the `Clock::now()` used to schedule 
> these timers can now be called when `__process__` is set! That led to a flaky 
> test when applying the above fix.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/clock.cpp b92d5de2631986506361e28c05cb6169e6632a70 
> 
> Diff: https://reviews.apache.org/r/31141/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

MesosCon 2015

[Benjamin Hindman]

Mesos Community!

I wanted to send out a little note "from the chair" about how excited I am
about the upcoming MesosCon 2015. The MesosCon program committee has been
doing a ton of amazing work and I'm confident that the conference is going
to be informative, thought provoking, and a lot of fun!

Both the early registration
<http://go.linuxfoundation.org/e/6342/vents-mesoscon-attend-register/ysqvd/599578631>
deadline and the speaking proposals
<http://go.linuxfoundation.org/e/6342/-events-mesoscon-program-cfp/ysqvj/599578631>
deadline
is this Saturday, February 14th, don't miss out!

Looking forward to seeing you all in Seattle this August!

Benjamin Hindman.

Re: Review Request 30884: Removed non-POD static function object in clock.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Feb. 11, 2015, 6:40 p.m., Ben Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30884/
> ---
> 
> (Updated Feb. 11, 2015, 6:40 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Jie Yu, and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-2344
> https://issues.apache.org/jira/browse/MESOS-2344
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> It looks like this is a possible source of the segfault mentioned by vinod 
> [in 
> MESOS-2344](https://issues.apache.org/jira/browse/MESOS-2344?focusedCommentId=14316710&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14316710).
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/clock.cpp fcc1eb0b921b3d9b9c033a17e5f6dcecf0a30f08 
> 
> Diff: https://reviews.apache.org/r/30884/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Re: Review Request 30587: Additional logging in libprocess

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Feb. 4, 2015, 12:06 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30587/
> ---
> 
> (Updated Feb. 4, 2015, 12:06 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Log when we drop a message since we can't find the local recipient.
> Include details of what was lost in a send failure.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/process.cpp 
> 67b6b3b9c13d95fa1a24b48a12c5c831c7f249bf 
> 
> Diff: https://reviews.apache.org/r/30587/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30194: Parse file:// arguments in

[Benjamin Hindman]

> On Feb. 11, 2015, 7:16 a.m., Benjamin Hindman wrote:
> >

Took care of the minor issue and committed.


- Benjamin


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


On Feb. 9, 2015, 12:43 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30194/
> ---
> 
> (Updated Feb. 9, 2015, 12:43 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ken Sipe.
> 
> 
> Bugs: mesos-1806
> https://issues.apache.org/jira/browse/mesos-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> More cases kept being added which dealt with 'file://' urls, parsing
> them, reading from the file, and then handling the argument as though
> the file:// wasn't there.
> 
> We now always read an argument from a file in the argument parser if
> it begins with 'file://'. If you want to pass an argument which is a
> filename, then just use the path directly.
> 
> Adds a new fetch<> step to parsing an argument which occurs before
> parse<>. This fetch can perform actions such as reading a file from
> the filesystem, or fetching a resource from a URL.
> 
> This is added to alleviate the need to keep adding more code to deal
> with 'file://' URLs in each new case where someone needs one.
> 
> The patchset introduces no outside-visible argument changes, but it
> does require developers who want to specify 'give me a path' to ask
> for that path using the new 'Path' type rather than a string, since
> for 'file://' URLs, we want to keep the filename.
> 
> All existing instances have been modified.
> 
> Specifying reading JSON from a file using an absolute path rather than
> a file:// URI has been deprecated, and will now log a deprecation
> message when used.
> 
> From a quick pass on JIRA (first page of results in JIRA searching for
> files): This would have prevented: MESOS-1368, MESOS-1635, MESOS-1590
> And simplifies supporting: MESOS-18
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/Makefile.am 
> dc3ef53dbb00bd205497bd86eec0c05e6b4395f1 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/fetch.hpp 
> PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/parse.hpp 
> 120946909cd19653ae5f71d401b5c9ea6d8228cd 
>   3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 
> 9f8f52040f22f995fb8b66a4078a0149ba26cca7 
>   3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
> 3b60ff824bada441cd657e10ca01762085a6d099 
> 
> Diff: https://reviews.apache.org/r/30194/diff/
> 
> 
> Testing
> ---
> 
> make distcheck when #30195 has been applied
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30195: Remove per-flag parsing of file:// arguments

[Benjamin Hindman]

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

Ship it!


Minor issues, I'll take care of them and get this committed.


docs/upgrades.md
<https://reviews.apache.org/r/30195/#comment117852>

s/mesos/Mesos/



src/zookeeper/url.hpp
<https://reviews.apache.org/r/30195/#comment117851>

Newline between these two please.


- Benjamin Hindman


On Feb. 9, 2015, 12:43 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30195/
> ---
> 
> (Updated Feb. 9, 2015, 12:43 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ken Sipe.
> 
> 
> Bugs: mesos-1806
> https://issues.apache.org/jira/browse/mesos-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Mostly simplifies things. There are two places where there things get
> complicated
> 
> 1. --whitelist: This code wants a file to watch for changes and update
>   the whitelist from periodically. Introduces Path to work around this.
> 2. --credential, --credentials: Custom parsing logic since the
>   credentials can be given in two different formats. Once the old
>   format is removed, either teaching  how to parse json
>   to protobuf generally or taking the flag as JSON then converting it
>   to protobuf later will make this clean.
> 
> 
> Diffs
> -
> 
>   CHANGELOG f515bc937441a2b4cc7e33bb857cb48a21aedea0 
>   docs/configuration.md 22f9e3db7b0e1691018de5fe3dfea3cb908de4b9 
>   docs/upgrades.md 51c7e70c7ddcd3d5f678872553a18eb27622f052 
>   src/credentials/credentials.hpp 9965858cedceecf29517f8a9b9430f3535164eb0 
>   src/examples/load_generator_framework.cpp 
> f803d9258b45fd406fcd57ee215418a9e932eb27 
>   src/master/contender.hpp 8e3e25aba8e93e13abf0815c9c547928f7ac2d7d 
>   src/master/contender.cpp 0a8c099e51ffb4f17c6d635472799c33441e943c 
>   src/master/detector.hpp 48107483150d90e3ebbc83ca4fac5cc872704ff1 
>   src/master/detector.cpp 367d1e1c76674c2376060ee18fe32fac2e091dc6 
>   src/master/flags.hpp df2e9cbdd56e9831290bf57c65b212cd7820a7f6 
>   src/master/main.cpp d4adae5a6044aef9f7cc214f0f467359b6f7a29a 
>   src/master/master.cpp 7c3aa220e72fdc156fb9a0998dd68beb7c464256 
>   src/slave/flags.hpp f6033355d129f0013d39dd053455c936596bf159 
>   src/slave/slave.cpp fff2d725fe49eee984d9151cfb2131202c47994f 
>   src/tests/credentials_tests.cpp e39db9e25d56d5688ac680a5bd0d1c525241999d 
>   src/tests/master_allocator_tests.cpp 
> 1eebefd2e423e4bb89d76ed7b7d8acc9d1bb7760 
>   src/tests/master_tests.cpp b52d2caa55d28d00e036f7e2142952f357a07aa3 
>   src/tests/mesos.cpp 21a405366f56c963611324076efe775f85b9d9f7 
>   src/watcher/whitelist_watcher.hpp 16ea839b364196b1b0f3997d915be8b49804876c 
>   src/watcher/whitelist_watcher.cpp 2a1586e92e1765edba28b89240d4eb44ce67840f 
>   src/zookeeper/url.hpp 16e711c5c0bc29b1967a20f0827238f8a7b0deaf 
> 
> Diff: https://reviews.apache.org/r/30195/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
>  - Tests not hitting the file:// handling which were replaced with CHECK() 
> statements.
> 
> gcc 4.4 + gcc 4.8
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30194: Parse file:// arguments in

[Benjamin Hindman]

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

Ship it!



3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp
<https://reviews.apache.org/r/30194/#comment117850>

Doesn't look like you needed to remove the 'const' from here.


- Benjamin Hindman


On Feb. 9, 2015, 12:43 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30194/
> ---
> 
> (Updated Feb. 9, 2015, 12:43 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ken Sipe.
> 
> 
> Bugs: mesos-1806
> https://issues.apache.org/jira/browse/mesos-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> More cases kept being added which dealt with 'file://' urls, parsing
> them, reading from the file, and then handling the argument as though
> the file:// wasn't there.
> 
> We now always read an argument from a file in the argument parser if
> it begins with 'file://'. If you want to pass an argument which is a
> filename, then just use the path directly.
> 
> Adds a new fetch<> step to parsing an argument which occurs before
> parse<>. This fetch can perform actions such as reading a file from
> the filesystem, or fetching a resource from a URL.
> 
> This is added to alleviate the need to keep adding more code to deal
> with 'file://' URLs in each new case where someone needs one.
> 
> The patchset introduces no outside-visible argument changes, but it
> does require developers who want to specify 'give me a path' to ask
> for that path using the new 'Path' type rather than a string, since
> for 'file://' URLs, we want to keep the filename.
> 
> All existing instances have been modified.
> 
> Specifying reading JSON from a file using an absolute path rather than
> a file:// URI has been deprecated, and will now log a deprecation
> message when used.
> 
> From a quick pass on JIRA (first page of results in JIRA searching for
> files): This would have prevented: MESOS-1368, MESOS-1635, MESOS-1590
> And simplifies supporting: MESOS-18
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/Makefile.am 
> dc3ef53dbb00bd205497bd86eec0c05e6b4395f1 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/fetch.hpp 
> PRE-CREATION 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/parse.hpp 
> 120946909cd19653ae5f71d401b5c9ea6d8228cd 
>   3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 
> 9f8f52040f22f995fb8b66a4078a0149ba26cca7 
>   3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
> 3b60ff824bada441cd657e10ca01762085a6d099 
> 
> Diff: https://reviews.apache.org/r/30194/diff/
> 
> 
> Testing
> ---
> 
> make distcheck when #30195 has been applied
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30792: Additonal use case for "auto" in C++ style guide: shared pointer creation.

[Benjamin Hindman]

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

Ship it!


I think this is a great use of auto!

- Benjamin Hindman


On Feb. 10, 2015, 11:37 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30792/
> ---
> 
> (Updated Feb. 10, 2015, 11:37 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Explicitly allows auto declarations for shared pointer creations. Example:
> 
> auto nameList = make_shared>();
> 
> Here the type on the left is already explicitly stated on the right. This 
> replaces
> 
> shared_ptr> nameList = make_shared>();
> 
> where we needlessly write the same type twice.
> 
> 
> Diffs
> -
> 
>   docs/mesos-c++-style-guide.md b24fe4b64a2577060f66ef49ae8b5d4a9d94167c 
> 
> Diff: https://reviews.apache.org/r/30792/diff/
> 
> 
> Testing
> ---
> 
> None. This is doc text only.
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 30774: Fetcher Cache

[Benjamin Hindman]

 downloads.

The abstraction I think you want here is something that lets you control 
what happens whenever we get a 'visit' callback, and to do that we really need 
to mock 'visit'. If you had a mocked 'visit' then you can explicitly control 
"how", and most importantly, "when" each 'visit' call occurs.



src/tests/fetcher_cache_tests.cpp
<https://reviews.apache.org/r/30774/#comment117379>

We've got a concurrent queue in libprocess called 'Queue'. See 
scheduler_tests.cpp for how it's used. I'd love to see the 'Enqueue' gmock 
action be made more generic so that you can use it here too (I'm confident it 
can, and can help if need be, and would rather use that then introduce another 
concurrent queuing like data structure, even if it's only for the tests).



src/tests/fetcher_cache_tests.cpp
<https://reviews.apache.org/r/30774/#comment117374>

Why aren't we being more explicit about what we're checking for here?



src/tests/fetcher_cache_tests.cpp
<https://reviews.apache.org/r/30774/#comment117377>

There is a ton of state, expectations, control flow requirements, etc, 
throughout these tests. This makes them very hard to follow, and thus hard to 
understand if you're really testing the things you want to test (i.e., 
concurrent requests, etc). While it's probably more code, I'd rather have seen 
each test case testing exactly what you wanted to test rather than a bunch of 
functions pulled out to cover "commonality". It makes it very difficult for me 
to determine if certain test situations are covered!

For example, in this function you await tasks if in "concurrent" mode. Yet, 
I'm pretty sure tasks aren't going to run in parallel unless there are enough 
resources to do so, and tracking down the size of the tasks and how many 
resources were launched with the slave is so non-local that it requires looking 
all over this source file and after doing so I'm not convinced that anything 
can actually run in parallel since the default slave has 2 CPUs and each task 
takes 1 CPU (so maybe 2 tasks run in parallel but not all of them?).

Why not be more explicit in the tests, even if it's more code, so that 
we're convinced we're testing the things we want to test? My guess is that 
there will still be things we can pull out and abstract after having done that.



src/tests/fetcher_cache_tests.cpp
<https://reviews.apache.org/r/30774/#comment117378>

How do you know that this index exists? Shouldn't we be doing a check 
before we loop through to make sure?


- Benjamin Hindman


On Feb. 8, 2015, 7:34 p.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30774/
> ---
> 
> (Updated Feb. 8, 2015, 7:34 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESOS-2057, MESOS-2069, MESOS-2070, MESOS-2072, and MESOS-2074
> https://issues.apache.org/jira/browse/MESOS-2057
> https://issues.apache.org/jira/browse/MESOS-2069
> https://issues.apache.org/jira/browse/MESOS-2070
> https://issues.apache.org/jira/browse/MESOS-2072
> https://issues.apache.org/jira/browse/MESOS-2074
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Replaces all other reviews for the fetcher cache except those related to 
> stout: 30006, 30033, 30034, 30036, 30037, 30039, 30124, 30173, 30614, 30616, 
> 30618, 30621, 30626. See descriptions of those.
> 
> 
> Diffs
> -
> 
>   include/mesos/fetcher/fetcher.proto 
> facb87b92bf3194516f636dcc348e136af537721 
>   include/mesos/mesos.proto 3a2921dff856d37455593dcbf7340aa537997d35 
>   src/Makefile.am 0fe4809542a7d23785a221901947771320b43d52 
>   src/hdfs/hdfs.hpp 968545d9af896f3e72e156484cc58135405cef6b 
>   src/launcher/fetcher.cpp 5b2d86d1867b25bf71461fd73df91b089002325b 
>   src/slave/constants.hpp 7717abd4f9a3bd6fdca6af2364864e374ce2e056 
>   src/slave/containerizer/docker.hpp 70114dcef7a416ae904e95eb9ce365bcd866aebc 
>   src/slave/containerizer/docker.cpp 813ddf8c98622748b2da1b739bf122387abc4c79 
>   src/slave/containerizer/fetcher.hpp 
> bfd98dbe16e2bd5df3e2c8e9b10e303654f33446 
>   src/slave/containerizer/fetcher.cpp 
> 6e6bce08d76bb8a5813c905e3ffeff9b2411fd6d 
>   src/slave/containerizer/mesos/containerizer.hpp 
> b3aafe4efa9f3469d7a3fd39243ad66b46d6a54d 
>   src/slave/containerizer/mesos/containerizer.cpp 
> fa40d47aee7803833bcde6cce1e86a21d7cf27d0 
>   src/slave/flags.hpp f6033355d129f0013d39dd053455c936596bf159 
>   src/slave/slave.cpp fff2d725fe49eee984d9151cfb2131202c47994f 
>   src/tests/docker_containerizer_tests.cpp 
> 8b212d4e6ed5a179ebadce1bdbbf3edde87d706c 
>   src/tests/fetcher_cache_tests.cpp PRE-CREATION 
>   src/tests/fetcher_tests.cpp fcbf7ad912f0b1b3d106a75a9dcb8213a0c69c07 
>   src/tests/mesos.hpp 83a369968ab2403fa341829ac5d11f7243095190 
>   src/tests/mesos.cpp 21a405366f56c963611324076efe775f85b9d9f7 
>   src/tests/mock_hadoop.sh PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/30774/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 30195: Remove per-flag parsing of file:// arguments

[Benjamin Hindman]

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



src/master/contender.cpp
<https://reviews.apache.org/r/30195/#comment117323>

How can this ever be the case? What path brings us to this that doesn't go 
through a flags load? Can you document as much for posterity?



src/master/contender.cpp
<https://reviews.apache.org/r/30195/#comment117324>

Why deprecate this? Are you just trying to force people to use flags? What 
are the paths where that doesn't work?



src/master/detector.cpp
<https://reviews.apache.org/r/30195/#comment117321>

See comment above.



src/tests/credentials_tests.cpp
<https://reviews.apache.org/r/30195/#comment117318>

Should this be s/flags/slaveFlags/ instead?



src/tests/master_allocator_tests.cpp
<https://reviews.apache.org/r/30195/#comment117319>

Why remove the 'file://' here?



src/tests/master_tests.cpp
<https://reviews.apache.org/r/30195/#comment117320>

Likewise here, see comment above.



src/zookeeper/url.hpp
<https://reviews.apache.org/r/30195/#comment117316>

s/char */char* /

And please move '{' to newline.


- Benjamin Hindman


On Feb. 7, 2015, 12:34 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30195/
> -------
> 
> (Updated Feb. 7, 2015, 12:34 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ken Sipe.
> 
> 
> Bugs: mesos-1806
> https://issues.apache.org/jira/browse/mesos-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Mostly simplifies things. There are two places where there things get
> complicated
> 
> 1. --whitelist: This code wants a file to watch for changes and update
>   the whitelist from periodically. Introduces Path to work around this.
> 2. --credential, --credentials: Custom parsing logic since the
>   credentials can be given in two different formats. Once the old
>   format is removed, either teaching  how to parse json
>   to protobuf generally or taking the flag as JSON then converting it
>   to protobuf later will make this clean.
> 
> 
> Diffs
> -
> 
>   CHANGELOG f515bc937441a2b4cc7e33bb857cb48a21aedea0 
>   docs/configuration.md 22f9e3db7b0e1691018de5fe3dfea3cb908de4b9 
>   docs/upgrades.md 51c7e70c7ddcd3d5f678872553a18eb27622f052 
>   src/credentials/credentials.hpp 4cdadb1b6d5a607cee8caeb38f2cbf2e3ec5da7a 
>   src/examples/load_generator_framework.cpp 
> 01a567b424140575ae0c369d026589300f173143 
>   src/master/contender.hpp 76beb5f973ae02507849233b6d73c43293669489 
>   src/master/contender.cpp c1bf82b621d6b46afe001acafe9ee53336726406 
>   src/master/detector.hpp 2905e2b3536e14e9df3570da172603e6ed81aae1 
>   src/master/detector.cpp 700eb9dde8e71648bacc00a82766634f77cf2d15 
>   src/master/flags.hpp 6c18a1af625311ef149b5877b08f63c2b12c040d 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
>   src/master/master.cpp d04b2c4041d8fe8978b877f07579a6f907903e1b 
>   src/slave/flags.hpp facf6d3e68e412897a1381d7bbdcceaf5d1fbb94 
>   src/slave/slave.cpp a8b262174ab5c9a524db8318d3d1438cd75a702b 
>   src/tests/credentials_tests.cpp 091b545c11cfa9deabf710366e15cfc0b966de0f 
>   src/tests/master_allocator_tests.cpp 
> 018a6ccba8bb78974de06398f423f1f30ef3a3df 
>   src/tests/master_tests.cpp 678d27f41a2f246c714c77adb132263c0c2c61ed 
>   src/tests/mesos.cpp 5ed4df530cf1bf11eec3b29542641822e0f702b2 
>   src/watcher/whitelist_watcher.hpp a1c1235a27512cf194cdeffc4ad7ca5ecd834f5c 
>   src/watcher/whitelist_watcher.cpp b6e73d7f500931dec69f115e554f9cd7cb42c3ed 
>   src/zookeeper/url.hpp 16e711c5c0bc29b1967a20f0827238f8a7b0deaf 
> 
> Diff: https://reviews.apache.org/r/30195/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
>  - Tests not hitting the file:// handling which were replaced with CHECK() 
> statements.
> 
> gcc 4.4 + gcc 4.8
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30588: etcd api wrapper

[Benjamin Hindman]

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



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117150>

And this can be const & now!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117151>

And this can be const & now!


- Benjamin Hindman


On Feb. 4, 2015, 12:10 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30588/
> ---
> 
> (Updated Feb. 4, 2015, 12:10 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> etcd api wrapper
> 
> 
> Diffs
> -
> 
>   src/Makefile.am 07bea1fb8f0035413f2119859e16fa4f9383f68e 
>   src/etcd/etcd.hpp PRE-CREATION 
>   src/etcd/etcd.cpp PRE-CREATION 
>   src/etcd/url.hpp PRE-CREATION 
>   src/etcd/url.cpp PRE-CREATION 
>   src/master/constants.hpp c386eab3973363e64c113f7e84452456fdd3393c 
>   src/master/constants.cpp 9ee17e9ad884da98cabfdfe316cb4a831de193b3 
> 
> Diff: https://reviews.apache.org/r/30588/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30588: etcd api wrapper

[Benjamin Hindman]

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



src/Makefile.am
<https://reviews.apache.org/r/30588/#comment117131>

Please align the '\' (and align the others below you if they're not, 
thanks!).



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117132>

s/ttl/TTL/

Captilize acroynms please!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117133>

s/.//



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117135>

s/auto/Address/
s/host/address/



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117136>

Newline here please!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117137>

Newline please!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117138>

Dead code!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117141>

How about a newline before you start the next "stanza" of text to show the 
reader that this is something else?



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117139>

No snake_case please!



src/etcd/etcd.cpp
<https://reviews.apache.org/r/30588/#comment117140>

No snake_case please!



src/etcd/url.hpp
<https://reviews.apache.org/r/30588/#comment117142>

I really don't see why we can't use an Address here?



src/etcd/url.hpp
<https://reviews.apache.org/r/30588/#comment117143>

Is it a server or a host? ;-) But let's just use Address!



src/etcd/url.hpp
<https://reviews.apache.org/r/30588/#comment117144>

'{' on newline! (For the struct above too, but let's just use Address!).



src/etcd/url.cpp
<https://reviews.apache.org/r/30588/#comment117145>

s/7/strlen(etcd::URL::scheme())/



src/etcd/url.cpp
<https://reviews.apache.org/r/30588/#comment117146>

Is it hosts or servers!?



src/etcd/url.cpp
<https://reviews.apache.org/r/30588/#comment117147>

Try> resolve = network::resolve(server);

if (resolve.isError()) {
  ...
}

if (resolve.get().empty()) {
  ...
}

// Just take the first address and give it a default port if necessary.
Address address = resolve.get().front();
address.port = address.port == 0 ? 4001;

addresses.push_back(address);



src/etcd/url.cpp
<https://reviews.apache.org/r/30588/#comment117149>

if (!strings::startsWith(pathStart, "/v2/keys/")) {



src/etcd/url.cpp
<https://reviews.apache.org/r/30588/#comment117148>

s/-1/ - 1/


- Benjamin Hindman


On Feb. 4, 2015, 12:10 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30588/
> ---
> 
> (Updated Feb. 4, 2015, 12:10 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> etcd api wrapper
> 
> 
> Diffs
> -
> 
>   src/Makefile.am 07bea1fb8f0035413f2119859e16fa4f9383f68e 
>   src/etcd/etcd.hpp PRE-CREATION 
>   src/etcd/etcd.cpp PRE-CREATION 
>   src/etcd/url.hpp PRE-CREATION 
>   src/etcd/url.cpp PRE-CREATION 
>   src/master/constants.hpp c386eab3973363e64c113f7e84452456fdd3393c 
>   src/master/constants.cpp 9ee17e9ad884da98cabfdfe316cb4a831de193b3 
> 
> Diff: https://reviews.apache.org/r/30588/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30589: etcd master contender + detector

[Benjamin Hindman]

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



src/master/contender.hpp
<https://reviews.apache.org/r/30589/#comment117113>

Alphabetical ordering please.



src/master/contender.hpp
<https://reviews.apache.org/r/30589/#comment117112>

Two newlines between top-level function and class declarations/definitions 
please.



src/master/contender.hpp
<https://reviews.apache.org/r/30589/#comment117110>

s/ &/& /



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117111>

Alphabetical ordering please.



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117115>

Thanks!



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117116>

Thanks!



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117117>

What, you don't like comments!? ;-)



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117118>

This comment does not seem correct.



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117119>

Why aren't we incrementing the index by 1? Comment!



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117120>

Should this comment say "Looks like we were _not_ able ..."?



src/master/contender.cpp
<https://reviews.apache.org/r/30589/#comment117121>

The comment below is much more helpful, what are you trying to say here?



src/master/detector.hpp
<https://reviews.apache.org/r/30589/#comment117122>

Alphabetical please.



src/master/detector.hpp
<https://reviews.apache.org/r/30589/#comment117123>

What's this about 'group session'?



src/master/detector.cpp
<https://reviews.apache.org/r/30589/#comment117124>

This is a perfectly fine comment to use above where we're extracting fields 
from the node for watching as well!



src/master/detector.cpp
<https://reviews.apache.org/r/30589/#comment117125>

s/masterInfo/MasterInfo from/



src/master/detector.cpp
<https://reviews.apache.org/r/30589/#comment117126>

Newline please!



src/master/detector.cpp
<https://reviews.apache.org/r/30589/#comment117130>

No period implies incomplete comment ... looks pretty incomplete to me! ;-)



src/master/detector.cpp
<https://reviews.apache.org/r/30589/#comment117128>

What is this line doing!?


- Benjamin Hindman


On Feb. 4, 2015, 12:10 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30589/
> ---
> 
> (Updated Feb. 4, 2015, 12:10 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> etcd master contender + detector
> 
> 
> Diffs
> -
> 
>   src/master/contender.hpp 76beb5f973ae02507849233b6d73c43293669489 
>   src/master/contender.cpp c1bf82b621d6b46afe001acafe9ee53336726406 
>   src/master/detector.hpp 2905e2b3536e14e9df3570da172603e6ed81aae1 
>   src/master/detector.cpp 700eb9dde8e71648bacc00a82766634f77cf2d15 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
>   src/slave/main.cpp 42e46c58ab4b16033ac6a73d127968d0803490aa 
> 
> Diff: https://reviews.apache.org/r/30589/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30591: Specify replicated log machines to coordinate with at the command line

[Benjamin Hindman]

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

Ship it!



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117073>

Did you finish this comment? Looks like you wanted to say something after 
the comma?



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117075>

= None();



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117074>

Please fix indentation.



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117106>

For now:

if (masters.isSome() && zk.isNone()) {



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117081>

Range based for is not supported by gcc 4.4!



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117099>

Let's just use network::resolve directly.



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117100>

s/decode/resolve/
s|hostname/ip|address|
s/:/ for/



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117101>

s/lookup/resolve/
s/ip/address/



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117103>

uint16_t port = addresses.get()[0].port;

replicas.insert(UPID("log-replica(1)", ip, port == 0 ? 5050 : port));



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117104>

Newline above and below this log line pleae!



src/master/main.cpp
<https://reviews.apache.org/r/30591/#comment117105>

s/.//


- Benjamin Hindman


On Feb. 4, 2015, 12:12 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30591/
> -------
> 
> (Updated Feb. 4, 2015, 12:12 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Adds a --masters option which is used in preference of --etcd or --zk
> and automatically figures out --quorum if that flag isn't set.
> 
> 
> Diffs
> -
> 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
> 
> Diff: https://reviews.apache.org/r/30591/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30590: Add --etcd to match --zk.

[Benjamin Hindman]

> On Feb. 6, 2015, 4:01 a.m., Benjamin Hindman wrote:
> > src/master/main.cpp, line 158
> > <https://reviews.apache.org/r/30590/diff/1/?file=846786#file846786line158>
> >
> > Why do we do determine this here? This should be determined down just 
> > before we do 'if (mechanism.isSome())'. Keep the declaration/definition as 
> > close to the use. Also, please initialize the value to 'None()'.

Seeing the next review I understand that you wanted to validate that not both 
--etcd and --zk are set. Why not just do that here and then only set mechanism 
futher down just before you need to use it. Keep 'if (zk.isSome())' for the 
replicated log checks (since it's weird to check 'if (mechanism.isSome())' when 
we're just doing ZooKeeper specific stuff) and then just before we create the 
contenders do:

Option mechanism = zk.isSome() ? zk : etcd;


- Benjamin


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


On Feb. 4, 2015, 12:11 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30590/
> -------
> 
> (Updated Feb. 4, 2015, 12:11 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Eventually these will be replaced with --masters which handles both
> calculating the master group as well as leader election. Currently
> etcd can only be used for master election.
> 
> 
> Diffs
> -
> 
>   docs/configuration.md 22f9e3db7b0e1691018de5fe3dfea3cb908de4b9 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
>   src/slave/main.cpp 42e46c58ab4b16033ac6a73d127968d0803490aa 
> 
> Diff: https://reviews.apache.org/r/30590/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30590: Add --etcd to match --zk.

[Benjamin Hindman]

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

Ship it!


Missed some comments.


docs/configuration.md
<https://reviews.apache.org/r/30590/#comment117079>

It's no longer "election".



docs/configuration.md
<https://reviews.apache.org/r/30590/#comment117080>

Not deprecated, please fix!



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117077>

Please do me a favor and add = None(); here and other places you come 
across that don't define a value for an Option, thanks!



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117078>

= None();


- Benjamin Hindman


On Feb. 4, 2015, 12:11 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30590/
> ---
> 
> (Updated Feb. 4, 2015, 12:11 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Eventually these will be replaced with --masters which handles both
> calculating the master group as well as leader election. Currently
> etcd can only be used for master election.
> 
> 
> Diffs
> -
> 
>   docs/configuration.md 22f9e3db7b0e1691018de5fe3dfea3cb908de4b9 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
>   src/slave/main.cpp 42e46c58ab4b16033ac6a73d127968d0803490aa 
> 
> Diff: https://reviews.apache.org/r/30590/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30590: Add --etcd to match --zk.

[Benjamin Hindman]

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

Ship it!



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117067>

s/zookeeper/ZooKeeper/
s/urls/URLs/



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117071>

Why do we do determine this here? This should be determined down just 
before we do 'if (mechanism.isSome())'. Keep the declaration/definition as 
close to the use. Also, please initialize the value to 'None()'.



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117068>

s/Error: //



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117069>

s/time./time/



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117070>

Kill newline please.



src/master/main.cpp
<https://reviews.apache.org/r/30590/#comment117072>

s/.//


- Benjamin Hindman


On Feb. 4, 2015, 12:11 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30590/
> ---
> 
> (Updated Feb. 4, 2015, 12:11 a.m.)
> 
> 
> Review request for mesos and Benjamin Hindman.
> 
> 
> Bugs: MESOS-1806
> https://issues.apache.org/jira/browse/MESOS-1806
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Eventually these will be replaced with --masters which handles both
> calculating the master group as well as leader election. Currently
> etcd can only be used for master election.
> 
> 
> Diffs
> -
> 
>   docs/configuration.md 22f9e3db7b0e1691018de5fe3dfea3cb908de4b9 
>   src/master/main.cpp e5e76ce16646eb0244227104038efeae5f2b 
>   src/slave/main.cpp 42e46c58ab4b16033ac6a73d127968d0803490aa 
> 
> Diff: https://reviews.apache.org/r/30590/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 30036: Introduced caching fields to command URI and fetcher parameter protobufs

[Benjamin Hindman]

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

Ship it!



include/mesos/mesos.proto
<https://reviews.apache.org/r/30036/#comment116899>

Can we add a small comment about semantics here? Specifically, if we've 
already cached and then run another command without 'cache' what will happen? 
Also, can we s/caching/cache/ to show the action?



src/slave/flags.hpp
<https://reviews.apache.org/r/30036/#comment116900>

Lets explain why we aren't nesting this in the work directory, i.e., it's 
not an automatic flag: (1) it's probably not meant to be backed up (that's a 
lot of data to back up) and (2) you might want to put it on a different disk.


- Benjamin Hindman


On Jan. 25, 2015, 11:27 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30036/
> ---
> 
> (Updated Jan. 25, 2015, 11:27 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESO-2069
> https://issues.apache.org/jira/browse/MESO-2069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Extends the CommandInfo::URI protobuf with a boolean "caching" field that 
> will later cause fetcher cache actions. Also introduces the notion of a cache 
> directory to the fetcher info protobuf. And then propagates these additions 
> throughout the rest of the code base where applicable. This includes passing 
> the slave ID all the way down to the place where the cache dir name is 
> constructed.
> 
> 
> Diffs
> -
> 
>   include/mesos/fetcher/fetcher.proto 
> facb87b92bf3194516f636dcc348e136af537721 
>   include/mesos/mesos.proto 26003fada2e4c4be0e9ebc4663f7ebab858cc48d 
>   src/launcher/fetcher.cpp fed0105946da579a38357a30e7ae56e646e05b89 
>   src/slave/containerizer/docker.hpp b7bf54ac65d6c61622e485ac253513eaac2e4f88 
>   src/slave/containerizer/docker.cpp 5f4b4ce49a9523e4743e5c79da4050e6f9e29ed7 
>   src/slave/containerizer/fetcher.hpp 
> 1db0eaf002c8d0eaf4e0391858e61e0912b35829 
>   src/slave/containerizer/fetcher.cpp 
> d290f95251def3952c5ee34f600e1d71467f6293 
>   src/slave/containerizer/mesos/containerizer.hpp 
> 802988c90ac872b0cefa5e28f06e6fec98e8d032 
>   src/slave/containerizer/mesos/containerizer.cpp 
> d712278428889ebdfd598537690138329d8464f0 
>   src/slave/flags.hpp a3c5c68a553b1c88ce6d5177e625079f7cdb2e5f 
>   src/tests/docker_containerizer_tests.cpp 
> 2105ae2c410f01e7e0d10241d5c00df143fd3439 
>   src/tests/fetcher_tests.cpp 8c0b0757eb388f1684d8b94393983f1844a769a7 
> 
> Diff: https://reviews.apache.org/r/30036/diff/
> 
> 
> Testing
> ---
> 
> make check.
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 30034: Unified fetcher testing, removed stderr/out redirection

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Jan. 20, 2015, 8:33 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30034/
> ---
> 
> (Updated Jan. 20, 2015, 8:33 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESOS-2069
> https://issues.apache.org/jira/browse/MESOS-2069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Makes the code structure of all fetcher tests the same. Instead of calling 
> the run mathod of the fetcher directly, calling through fetch(). Also removes 
> all uses of I/O redirection, which is not really needed for debugging, and 
> thus the next patch can refactor fetch() and run(). (The latter comes in two 
> varieties, which complicates matters without much benefit.)
> 
> 
> Diffs
> -
> 
>   src/tests/fetcher_tests.cpp 8c0b0757eb388f1684d8b94393983f1844a769a7 
> 
> Diff: https://reviews.apache.org/r/30034/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 30033: Removed fetcher env tests

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Jan. 19, 2015, 3:45 p.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30033/
> ---
> 
> (Updated Jan. 19, 2015, 3:45 p.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESOS-2069
> https://issues.apache.org/jira/browse/MESOS-2069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removes the fetcher env tests since these won't be needed any more when the 
> fetcher uses JSON in a single env var as a parameter. They never tested 
> anything that won't be covered by other tests anyway.
> 
> 
> Diffs
> -
> 
>   src/tests/fetcher_tests.cpp 8c0b0757eb388f1684d8b94393983f1844a769a7 
> 
> Diff: https://reviews.apache.org/r/30033/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 28697: Added ReservationType for dynamic reservations.

[Benjamin Hindman]

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

Ship it!


Ship It!

- Benjamin Hindman


On Jan. 29, 2015, 6:10 a.m., Michael Park wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/28697/
> ---
> 
> (Updated Jan. 29, 2015, 6:10 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Jie Yu, and 
> Vinod Kone.
> 
> 
> Bugs: MESOS-2137
> https://issues.apache.org/jira/browse/MESOS-2137
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Adding new protobuf messages necessary to support dynamic reservations.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 540071db64961466eb75c779b3ea6863f4594437 
> 
> Diff: https://reviews.apache.org/r/28697/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Michael Park
> 
>