Re: Review Request 26701: Updated master to update task unacknowledged state properly.

[Adam B]

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



src/master/master.cpp


s/unacknowleded/unacknowledged/



src/master/master.cpp


When would the uuids ever be different? If the scheduler re-acked a 
previous terminal update when the master expected to be on a second terminal 
update/ack?



src/master/master.cpp


s/do prevent/do, prevent/



src/messages/messages.proto


s/lateset/latest/


- Adam B


On Oct. 14, 2014, 11:06 a.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26701/
> ---
> 
> (Updated Oct. 14, 2014, 11:06 a.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Master now maintains the latest and unacknowledged states of the task.
> 
> 
> Diffs
> -
> 
>   src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/tests/master_tests.cpp d9dc40c6f5aaa66e1f7a0e1b7e4d9cdc586ca0fd 
> 
> Diff: https://reviews.apache.org/r/26701/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran the new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Running Docker Tests

[Timothy Chen]

Hi Ryan,

You need to enable cgroups, mount the cpu subsystem and run your tests
under root to run the docker tests.

Also you need to run on Linux with docker version at least 1.0+ with
docker daemon running.

The warning you saw for the CgroupsNoHierarchyTest is specifically for
that set of tests, so ignore them while you try to run the docker
tests.

Tim

On Tue, Oct 14, 2014 at 10:05 PM, Ryan Thomas  wrote:
> Hi, I am trying to run the docker test-suite for some changes that I have
> made, and I am encountering the following situation which I can't seem to
> remedy.
>
> After doing a full make check, I attempt to run the tests like this:
>
> $ bin/mesos-tests.sh --gtest_filter="Docker" --verbose
>
> However, I get a warning about cgroups:
>
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu, /sys/fs/cgroup/cpuacct,
> /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer,
> /sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory, /sys/fs/cgroup/perf_event
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
>
> The issue is if I unmount the groups, I get the following issue:
>
> We cannot run any Docker tests because:
> Failed to find a mounted cgroups hierarchy for the 'cpu' subsystem; you
> probably need to mount cgroups manually!
>
>
> Could someone please offer some guidance on getting the docker tests to run?
>
> Cheers,
>
> Ryan

Re: Review Request 26702: Updated reconciliation semantics to take the task's unacknowledged state into account.

[Adam B]

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



src/master/master.cpp


Should reconciliation on slave reregistration return to the slave each 
task's latest state, or its latest unacknowledged state? Would it ever matter?
Looking at Slave::reregistered(), it seems it doesn't even look at the 
state. It just checks to see if the slave knows that taskID and sends back 
TASK_LOST if the task is unknown.



src/tests/reconciliation_tests.cpp


Times(1) is implicit, unnecessary.



src/tests/reconciliation_tests.cpp


Validate uuid?


- Adam B


On Oct. 14, 2014, 11:07 a.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26702/
> ---
> 
> (Updated Oct. 14, 2014, 11:07 a.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Master responds to reconciliation requests with unacknowledged state of task 
> instead of latest state.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
>   src/tests/reconciliation_tests.cpp 400c5c035a2cadd408636021aafb3888546f0081 
> 
> Diff: https://reviews.apache.org/r/26702/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 23912: Fix MESOS-947: Slave should properly handle a killTask() that arrives between runTask() and _runTask()

[Bernd Mathiske]

> On Oct. 10, 2014, 11:24 a.m., Vinod Kone wrote:
> > src/slave/slave.cpp, line 1413
> > 
> >
> > It is weird to me that you remove the task here but (potentially) 
> > remove the executor up in _runTask(). It's not obvious to me why you made 
> > that choice. If there is a good reason, please add a comment here.
> 
> Bernd Mathiske wrote:
> The task is removed in killTask(), because later on the information that 
> it should be removed is no longer easily at hand.
> 
> I looked at lines 1194, 1195 in _runTask():
>   Framework* framework = getFramework(frameworkId);
>   CHECK_NOTNULL(framework);
>   
> If I removed the framework earlier than this, this check would fire. If I 
> want to avoid that, I need to write extra code (e.g. prevent _runTask() from 
> happening). Assembling all framework removals in the second half of 
> _runTask() looks like good defensive practice to me.
> 
> There is no harm in removing the framework in _runTask() vs. killTask() 
> since _runTask() must eventually happen. But by waiting with removing the 
> framework until _runTask(), we do not need to think about what implications 
> concurrent starting and killing of multiple tasks with the same executor 
> might have.
> 
> Vinod Kone wrote:
> I don't think I follow what you mean by
> 
> "The task is removed in killTask(), because later on the information that 
> it should be removed is no longer easily at hand"
> 
> and 
> 
> "...we do not need to think about what implications concurrent starting 
> and killing of multiple tasks with the same executor might have"
> 
> 
> Anyway, here's why I think we should remove the framework in killTask().
> 
> It doesn't require non-local reasoning. Right now, someone reading the 
> killTask() method should know that a pending task means a "_runTask()" 
> dispatch is in the queue and that the executor and framework will be removed 
> in '_runTask()'. Instead if killTask() can remove the framework right away, 
> it's easy to understand.
> 
> It is much simple for methods that take "FrameworkID" (instead of 
> Framework*) to check if the framework exists. If the framework doesn't exist, 
> for whatever reason, it could just bail.
> 
> I think these semantics would make future contributors' life easy when 
> making changes to these methods.
> 
> Changing the CHECK in '_runTask()' to an if condition doesn't seem too 
> bad to me.
> 
> ```
> _runTask()
> {
>if (framework == NULL) {
>  LOG(WARNING) << "Ignoring run task " << task
>   << " because the framework does not exist";
>   
>  return;
>}
> }
> ```
> 
> Makes sense?

This is more confusing for the user. He will then ask himself "why does the 
framework not exist"? And then have to track back in the log to find that the 
task has been killed. Making it simpler for users trumps making it simpler for 
us Mesos developers IMHO.


- Bernd


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


On Oct. 14, 2014, 2:54 p.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23912/
> ---
> 
> (Updated Oct. 14, 2014, 2:54 p.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-947
> https://issues.apache.org/jira/browse/MESOS-947
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Fixes MESOS-947 "Slave should properly handle a killTask() that arrives 
> between runTask() and _runTask()".
> 
> Slave::killTask() did not check for task in question combination to be 
> "pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet) 
> and then erroneously assumed that Slave::runTask() had not been executed. The 
> task was then marked "LOST" instead of "KILLED". But Slave::runTask had 
> already scheduled Slave::_runTask to follow. Now the entry for being 
> "pending" is removed, and the task is marked "KILLED", and _runTask gets 
> informed about this. It checks whether the task in question is currently 
> "pending" and if it is not, then it infers that the task has been killed and 
> does not erroneously try to complete launching it.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
>   src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
>   src/tests/slave_tests.cpp f585b

Re: Review Request 23912: Fix MESOS-947: Slave should properly handle a killTask() that arrives between runTask() and _runTask()

[Bernd Mathiske]

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

(Updated Oct. 15, 2014, 1:03 a.m.)


Review request for mesos and Vinod Kone.


Changes
---

Fixed constructor parameter indentation.


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


Repository: mesos-git


Description
---

Fixes MESOS-947 "Slave should properly handle a killTask() that arrives between 
runTask() and _runTask()".

Slave::killTask() did not check for task in question combination to be 
"pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet) 
and then erroneously assumed that Slave::runTask() had not been executed. The 
task was then marked "LOST" instead of "KILLED". But Slave::runTask had already 
scheduled Slave::_runTask to follow. Now the entry for being "pending" is 
removed, and the task is marked "KILLED", and _runTask gets informed about 
this. It checks whether the task in question is currently "pending" and if it 
is not, then it infers that the task has been killed and does not erroneously 
try to complete launching it.


Diffs (updated)
-

  src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
  src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
  src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
  src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
  src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 

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


Testing
---

Wrote a unit test that reliably created the situation described in the ticket. 
Observed that TASK_LOST and the listed log output occurred. This pointed 
directly to the lines in killTask() where the problem is rooted. Ran the test 
after fixing, it succeeded. Checked the log. It looks like a "clean kill" now 
:-)


Thanks,

Bernd Mathiske

Re: Review Request 23912: Fix MESOS-947: Slave should properly handle a killTask() that arrives between runTask() and _runTask()

[Bernd Mathiske]

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

(Updated Oct. 15, 2014, 1:06 a.m.)


Review request for mesos and Vinod Kone.


Changes
---

Now really fixed constructor parameter indentation.


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


Repository: mesos-git


Description
---

Fixes MESOS-947 "Slave should properly handle a killTask() that arrives between 
runTask() and _runTask()".

Slave::killTask() did not check for task in question combination to be 
"pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet) 
and then erroneously assumed that Slave::runTask() had not been executed. The 
task was then marked "LOST" instead of "KILLED". But Slave::runTask had already 
scheduled Slave::_runTask to follow. Now the entry for being "pending" is 
removed, and the task is marked "KILLED", and _runTask gets informed about 
this. It checks whether the task in question is currently "pending" and if it 
is not, then it infers that the task has been killed and does not erroneously 
try to complete launching it.


Diffs (updated)
-

  src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
  src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
  src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
  src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
  src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 

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


Testing
---

Wrote a unit test that reliably created the situation described in the ticket. 
Observed that TASK_LOST and the listed log output occurred. This pointed 
directly to the lines in killTask() where the problem is rooted. Ran the test 
after fixing, it succeeded. Checked the log. It looks like a "clean kill" now 
:-)


Thanks,

Bernd Mathiske

Re: Running Docker Tests

[Ryan Thomas]

Thanks Tim, I'm not sure what I'm doing wrong here, as it complains about
the cpu group being mounted (and runs no tests).

$ sudo bin/mesos-tests.sh --gtest_filter="DockerTest" --verbose
Source directory: /vagrant
Build directory: /vagrant/build
-
We cannot run any cgroups tests that require mounting
hierarchies because you have the following hierarchies mounted:
/sys/fs/cgroup/cpu
We'll disable the CgroupsNoHierarchyTest test fixture for now.
-
Note: Google Test filter =
DockerTest-CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy:SlaveCount/Registrar_BENCHMARK_Test.performance/0:SlaveCount/Registrar_BENCHMARK_Test.performance/1:SlaveCount/Registrar_BENCHMARK_Test.performance/2:SlaveCount/Registrar_BENCHMARK_Test.performance/3
[==] Running 0 tests from 0 test cases.
[==] 0 tests from 0 test cases ran. (0 ms total)
[  PASSED  ] 0 tests.

  YOU HAVE 6 DISABLED TESTS


Am I specifying the wrong filter field for just the docker tests?

Cheers,

Ryan

On 15 October 2014 18:25, Timothy Chen  wrote:

> Hi Ryan,
>
> You need to enable cgroups, mount the cpu subsystem and run your tests
> under root to run the docker tests.
>
> Also you need to run on Linux with docker version at least 1.0+ with
> docker daemon running.
>
> The warning you saw for the CgroupsNoHierarchyTest is specifically for
> that set of tests, so ignore them while you try to run the docker
> tests.
>
> Tim
>
> On Tue, Oct 14, 2014 at 10:05 PM, Ryan Thomas  wrote:
> > Hi, I am trying to run the docker test-suite for some changes that I have
> > made, and I am encountering the following situation which I can't seem to
> > remedy.
> >
> > After doing a full make check, I attempt to run the tests like this:
> >
> > $ bin/mesos-tests.sh --gtest_filter="Docker" --verbose
> >
> > However, I get a warning about cgroups:
> >
> > We cannot run any cgroups tests that require mounting
> > hierarchies because you have the following hierarchies mounted:
> > /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu, /sys/fs/cgroup/cpuacct,
> > /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer,
> > /sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory, /sys/fs/cgroup/perf_event
> > We'll disable the CgroupsNoHierarchyTest test fixture for now.
> >
> > The issue is if I unmount the groups, I get the following issue:
> >
> > We cannot run any Docker tests because:
> > Failed to find a mounted cgroups hierarchy for the 'cpu' subsystem; you
> > probably need to mount cgroups manually!
> >
> >
> > Could someone please offer some guidance on getting the docker tests to
> run?
> >
> > Cheers,
> >
> > Ryan
>

Re: Review Request 23912: Fix MESOS-947: Slave should properly handle a killTask() that arrives between runTask() and _runTask()

[Bernd Mathiske]

> On Oct. 14, 2014, 3:33 p.m., Vinod Kone wrote:
> > src/tests/mesos.cpp, lines 343-345
> > 
> >
> > Sorry, missed this earlier. We align constructor arguments as follows:
> > 
> > MockSlave::MockSlave(const slave::Flags& flags,
> >  MasterDetector* detector,
> >  slave::Containerizer* containerizer);

The review tool does not show or mark the code area that this concerns. But if 
you scroll up from what it does show, you can see the changes for line 344 and 
345 in revision 12.


- Bernd


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


On Oct. 15, 2014, 1:06 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23912/
> ---
> 
> (Updated Oct. 15, 2014, 1:06 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-947
> https://issues.apache.org/jira/browse/MESOS-947
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Fixes MESOS-947 "Slave should properly handle a killTask() that arrives 
> between runTask() and _runTask()".
> 
> Slave::killTask() did not check for task in question combination to be 
> "pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet) 
> and then erroneously assumed that Slave::runTask() had not been executed. The 
> task was then marked "LOST" instead of "KILLED". But Slave::runTask had 
> already scheduled Slave::_runTask to follow. Now the entry for being 
> "pending" is removed, and the task is marked "KILLED", and _runTask gets 
> informed about this. It checks whether the task in question is currently 
> "pending" and if it is not, then it infers that the task has been killed and 
> does not erroneously try to complete launching it.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
>   src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
>   src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 
> 
> Diff: https://reviews.apache.org/r/23912/diff/
> 
> 
> Testing
> ---
> 
> Wrote a unit test that reliably created the situation described in the 
> ticket. Observed that TASK_LOST and the listed log output occurred. This 
> pointed directly to the lines in killTask() where the problem is rooted. Ran 
> the test after fixing, it succeeded. Checked the log. It looks like a "clean 
> kill" now :-)
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Running Docker Tests

[Timothy Chen]

Hi Ryan,

The gtest_filter is doing a exact match, so it won't find any test
that is named "DockerTest".

Try using gtest_filter=*DOCKER*

Tim

On Wed, Oct 15, 2014 at 1:07 AM, Ryan Thomas  wrote:
> Thanks Tim, I'm not sure what I'm doing wrong here, as it complains about
> the cpu group being mounted (and runs no tests).
>
> $ sudo bin/mesos-tests.sh --gtest_filter="DockerTest" --verbose
> Source directory: /vagrant
> Build directory: /vagrant/build
> -
> We cannot run any cgroups tests that require mounting
> hierarchies because you have the following hierarchies mounted:
> /sys/fs/cgroup/cpu
> We'll disable the CgroupsNoHierarchyTest test fixture for now.
> -
> Note: Google Test filter =
> DockerTest-CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy:SlaveCount/Registrar_BENCHMARK_Test.performance/0:SlaveCount/Registrar_BENCHMARK_Test.performance/1:SlaveCount/Registrar_BENCHMARK_Test.performance/2:SlaveCount/Registrar_BENCHMARK_Test.performance/3
> [==] Running 0 tests from 0 test cases.
> [==] 0 tests from 0 test cases ran. (0 ms total)
> [  PASSED  ] 0 tests.
>
>   YOU HAVE 6 DISABLED TESTS
>
>
> Am I specifying the wrong filter field for just the docker tests?
>
> Cheers,
>
> Ryan
>
> On 15 October 2014 18:25, Timothy Chen  wrote:
>
>> Hi Ryan,
>>
>> You need to enable cgroups, mount the cpu subsystem and run your tests
>> under root to run the docker tests.
>>
>> Also you need to run on Linux with docker version at least 1.0+ with
>> docker daemon running.
>>
>> The warning you saw for the CgroupsNoHierarchyTest is specifically for
>> that set of tests, so ignore them while you try to run the docker
>> tests.
>>
>> Tim
>>
>> On Tue, Oct 14, 2014 at 10:05 PM, Ryan Thomas  wrote:
>> > Hi, I am trying to run the docker test-suite for some changes that I have
>> > made, and I am encountering the following situation which I can't seem to
>> > remedy.
>> >
>> > After doing a full make check, I attempt to run the tests like this:
>> >
>> > $ bin/mesos-tests.sh --gtest_filter="Docker" --verbose
>> >
>> > However, I get a warning about cgroups:
>> >
>> > We cannot run any cgroups tests that require mounting
>> > hierarchies because you have the following hierarchies mounted:
>> > /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu, /sys/fs/cgroup/cpuacct,
>> > /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer,
>> > /sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory, /sys/fs/cgroup/perf_event
>> > We'll disable the CgroupsNoHierarchyTest test fixture for now.
>> >
>> > The issue is if I unmount the groups, I get the following issue:
>> >
>> > We cannot run any Docker tests because:
>> > Failed to find a mounted cgroups hierarchy for the 'cpu' subsystem; you
>> > probably need to mount cgroups manually!
>> >
>> >
>> > Could someone please offer some guidance on getting the docker tests to
>> run?
>> >
>> > Cheers,
>> >
>> > Ryan
>>

Re: Running Docker Tests

[Ryan Thomas]

Great, thanks mate!

One step closer :)

Cheers,

Ryan

On 15 October 2014 19:13, Timothy Chen  wrote:

> Hi Ryan,
>
> The gtest_filter is doing a exact match, so it won't find any test
> that is named "DockerTest".
>
> Try using gtest_filter=*DOCKER*
>
> Tim
>
> On Wed, Oct 15, 2014 at 1:07 AM, Ryan Thomas  wrote:
> > Thanks Tim, I'm not sure what I'm doing wrong here, as it complains about
> > the cpu group being mounted (and runs no tests).
> >
> > $ sudo bin/mesos-tests.sh --gtest_filter="DockerTest" --verbose
> > Source directory: /vagrant
> > Build directory: /vagrant/build
> > -
> > We cannot run any cgroups tests that require mounting
> > hierarchies because you have the following hierarchies mounted:
> > /sys/fs/cgroup/cpu
> > We'll disable the CgroupsNoHierarchyTest test fixture for now.
> > -
> > Note: Google Test filter =
> >
> DockerTest-CgroupsNoHierarchyTest.ROOT_CGROUPS_NOHIERARCHY_MountUnmountHierarchy:SlaveCount/Registrar_BENCHMARK_Test.performance/0:SlaveCount/Registrar_BENCHMARK_Test.performance/1:SlaveCount/Registrar_BENCHMARK_Test.performance/2:SlaveCount/Registrar_BENCHMARK_Test.performance/3
> > [==] Running 0 tests from 0 test cases.
> > [==] 0 tests from 0 test cases ran. (0 ms total)
> > [  PASSED  ] 0 tests.
> >
> >   YOU HAVE 6 DISABLED TESTS
> >
> >
> > Am I specifying the wrong filter field for just the docker tests?
> >
> > Cheers,
> >
> > Ryan
> >
> > On 15 October 2014 18:25, Timothy Chen  wrote:
> >
> >> Hi Ryan,
> >>
> >> You need to enable cgroups, mount the cpu subsystem and run your tests
> >> under root to run the docker tests.
> >>
> >> Also you need to run on Linux with docker version at least 1.0+ with
> >> docker daemon running.
> >>
> >> The warning you saw for the CgroupsNoHierarchyTest is specifically for
> >> that set of tests, so ignore them while you try to run the docker
> >> tests.
> >>
> >> Tim
> >>
> >> On Tue, Oct 14, 2014 at 10:05 PM, Ryan Thomas  wrote:
> >> > Hi, I am trying to run the docker test-suite for some changes that I
> have
> >> > made, and I am encountering the following situation which I can't
> seem to
> >> > remedy.
> >> >
> >> > After doing a full make check, I attempt to run the tests like this:
> >> >
> >> > $ bin/mesos-tests.sh --gtest_filter="Docker" --verbose
> >> >
> >> > However, I get a warning about cgroups:
> >> >
> >> > We cannot run any cgroups tests that require mounting
> >> > hierarchies because you have the following hierarchies mounted:
> >> > /sys/fs/cgroup/blkio, /sys/fs/cgroup/cpu, /sys/fs/cgroup/cpuacct,
> >> > /sys/fs/cgroup/cpuset, /sys/fs/cgroup/devices, /sys/fs/cgroup/freezer,
> >> > /sys/fs/cgroup/hugetlb, /sys/fs/cgroup/memory,
> /sys/fs/cgroup/perf_event
> >> > We'll disable the CgroupsNoHierarchyTest test fixture for now.
> >> >
> >> > The issue is if I unmount the groups, I get the following issue:
> >> >
> >> > We cannot run any Docker tests because:
> >> > Failed to find a mounted cgroups hierarchy for the 'cpu' subsystem;
> you
> >> > probably need to mount cgroups manually!
> >> >
> >> >
> >> > Could someone please offer some guidance on getting the docker tests
> to
> >> run?
> >> >
> >> > Cheers,
> >> >
> >> > Ryan
> >>
>

Re: Review Request 26723: Escape JSON object keys

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26723]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 1:12 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26723/
> ---
> 
> (Updated Oct. 15, 2014, 1:12 a.m.)
> 
> 
> Review request for mesos and Adam B.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> All strings in JSON need to be escaped, including the keys in dictionaries / 
> objects.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 719aa964a536cf02dbd2de440157de487ec703b1 
> 
> Diff: https://reviews.apache.org/r/26723/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Review Request 26734: Ensure docker calls stop if a docker_stop_timeout is provided

[Ryan Thomas]

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

Review request for mesos.


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


Repository: mesos-git


Description
---

Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the 
a docker kill will be run, otherwise a docker stop with the timeout in seconds 
is used. A negative value will result in a Failure.


Diffs
-

  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
  src/tests/docker_containerizer_tests.cpp 
67d60a885d65edbcbbf702bce83a54d1a5c0411f 
  src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 

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


Testing
---


Thanks,

Ryan Thomas

Re: Review Request 26734: Ensure docker calls stop if a docker_stop_timeout is provided

[Ryan Thomas]

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

(Updated Oct. 15, 2014, 9:01 a.m.)


Review request for mesos.


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


Repository: mesos-git


Description (updated)
---

Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the 
a docker kill will be run, otherwise a docker stop with the timeout in seconds 
is used. A negative value will result in a Failure.


Diffs
-

  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
  src/tests/docker_containerizer_tests.cpp 
67d60a885d65edbcbbf702bce83a54d1a5c0411f 
  src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 

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


Testing (updated)
---

make check
sudo bin/mesos-tests.sh --gtest_filter="*DOCKER*" --verbose


Thanks,

Ryan Thomas

Re: Review Request 23912: Fix MESOS-947: Slave should properly handle a killTask() that arrives between runTask() and _runTask()

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [23912]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 8:06 a.m., Bernd Mathiske wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23912/
> ---
> 
> (Updated Oct. 15, 2014, 8:06 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-947
> https://issues.apache.org/jira/browse/MESOS-947
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Fixes MESOS-947 "Slave should properly handle a killTask() that arrives 
> between runTask() and _runTask()".
> 
> Slave::killTask() did not check for task in question combination to be 
> "pending" (i.e. Slave::runTask had happened, but Slave::_runTask had not yet) 
> and then erroneously assumed that Slave::runTask() had not been executed. The 
> task was then marked "LOST" instead of "KILLED". But Slave::runTask had 
> already scheduled Slave::_runTask to follow. Now the entry for being 
> "pending" is removed, and the task is marked "KILLED", and _runTask gets 
> informed about this. It checks whether the task in question is currently 
> "pending" and if it is not, then it infers that the task has been killed and 
> does not erroneously try to complete launching it.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
>   src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
>   src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 
> 
> Diff: https://reviews.apache.org/r/23912/diff/
> 
> 
> Testing
> ---
> 
> Wrote a unit test that reliably created the situation described in the 
> ticket. Observed that TASK_LOST and the listed log output occurred. This 
> pointed directly to the lines in killTask() where the problem is rooted. Ran 
> the test after fixing, it succeeded. Checked the log. It looks like a "clean 
> kill" now :-)
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Re: Review Request 26734: Ensure docker calls stop if a docker_stop_timeout is provided

[Mesos ReviewBot]

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


Bad patch!

Reviews applied: [26734]

Failed command: ./support/mesos-style.py

Error:
 Checking 519 files using filter 
--filter=-,+build/class,+build/deprecated,+build/endif_comment,+readability/todo,+readability/namespace,+runtime/vlog,+whitespace/blank_line,+whitespace/comma,+whitespace/end_of_line,+whitespace/ending_newline,+whitespace/forcolon,+whitespace/indent,+whitespace/line_length,+whitespace/operators,+whitespace/semicolon,+whitespace/tab,+whitespace/todo
src/slave/flags.hpp:333:  Redundant blank line at the end of a code block 
should be deleted.  [whitespace/blank_line] [3]
src/slave/containerizer/docker.cpp:1570:  Lines should be <= 80 characters long 
 [whitespace/line_length] [2]
src/docker/docker.cpp:469:  Line ends in whitespace.  Consider deleting these 
extra spaces.  [whitespace/end_of_line] [4]
src/docker/docker.cpp:471:  Lines should be <= 80 characters long  
[whitespace/line_length] [2]
Total errors found: 4

- Mesos ReviewBot


On Oct. 15, 2014, 9:01 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26734/
> ---
> 
> (Updated Oct. 15, 2014, 9:01 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 
> the a docker kill will be run, otherwise a docker stop with the timeout in 
> seconds is used. A negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26734/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="*DOCKER*" --verbose
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26734: Ensure docker calls stop if a docker_stop_timeout is provided

[Ryan Thomas]

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

(Updated Oct. 15, 2014, 10:25 a.m.)


Review request for mesos.


Changes
---

Update diff with style fixes.


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


Repository: mesos-git


Description
---

Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the 
a docker kill will be run, otherwise a docker stop with the timeout in seconds 
is used. A negative value will result in a Failure.


Diffs (updated)
-

  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 

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


Testing
---

make check
sudo bin/mesos-tests.sh --gtest_filter="*DOCKER*" --verbose


Thanks,

Ryan Thomas

Re: Review Request 26734: Ensure docker calls stop if a docker_stop_timeout is provided

[Mesos ReviewBot]

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


Bad patch!

Reviews applied: [26734]

Failed command: git apply --index 26734.patch

Error:
 error: patch failed: src/docker/docker.cpp:466
error: src/docker/docker.cpp: patch does not apply
error: patch failed: src/slave/containerizer/docker.cpp:1567
error: src/slave/containerizer/docker.cpp: patch does not apply
error: patch failed: src/slave/flags.hpp:330
error: src/slave/flags.hpp: patch does not apply

- Mesos ReviewBot


On Oct. 15, 2014, 10:25 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26734/
> ---
> 
> (Updated Oct. 15, 2014, 10:25 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 
> the a docker kill will be run, otherwise a docker stop with the timeout in 
> seconds is used. A negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
> 
> Diff: https://reviews.apache.org/r/26734/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="*DOCKER*" --verbose
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ryan Thomas]

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

(Updated Oct. 15, 2014, 10:58 a.m.)


Review request for mesos.


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


Repository: mesos-git


Description (updated)
---

Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
will be run, otherwise a docker stop with the timeout in seconds is used. A 
negative value will result in a Failure.


Diffs
-

  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
  src/tests/docker_containerizer_tests.cpp 
67d60a885d65edbcbbf702bce83a54d1a5c0411f 
  src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 

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


Testing (updated)
---

make check
sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
support/mesos-style.py


Thanks,

Ryan Thomas

Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherwise

[Ryan Thomas]

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

Review request for mesos.


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


Repository: mesos-git


Description
---

Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
will be run, otherwise a docker stop with the timeout in seconds is used. A 
negative value will result in a Failure.


Diffs
-

  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
  src/tests/docker_containerizer_tests.cpp 
67d60a885d65edbcbbf702bce83a54d1a5c0411f 
  src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 

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


Testing
---


Thanks,

Ryan Thomas

Re: Review Request 26605: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:23 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
37e007e9ee3010d9aacf2de6254abb75b716412d 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
ab609a0d7922298eaf89648200fabd843f8201e0 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
  3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp 
89e77bf75c642c00ac9e0d36a3dbe71838e0efab 
  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
719aa964a536cf02dbd2de440157de487ec703b1 
  3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp 
89340fd79167a311c698740454db19e83c286952 
  3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
ec41fe412290a152a15a49e091f0bc6436e42cfd 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp 
fa1950cc8849fcd81d425c651848e0566078 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/linux.hpp 
7a5573be8d8be537e5fd85b86e322fd5765c54ab 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/ls.hpp 
7cd4a40f57a661d83d1726c65fd8c898072e809b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/osx.hpp 
7d17249cf1d14e9344112dd7fef7230c2ad8 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/pstree.hpp 
e7fe077f763518680ba13d609dba9ea26950210d 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/setns.hpp 
5278996f201a4a3d69282c1bd7b0d230d0f6cd39 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/sysctl.hpp 
a1e6e4d131e15c31135d72399e5e6825e7dd0141 
  3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp 
0004fa5cd249269504155e51e52cd802c0916851 
  3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
3b30ab7ec93a94dc69b4c817a15a16317520fa74 
  3rdparty/libprocess/3rdparty/stout/include/stout/strings.hpp 
01e47ff21574d22f9469ab3bafd458322f6849c9 
  3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
3b60ff824bada441cd657e10ca01762085a6d099 
  3rdparty/libprocess/3rdparty/stout/tests/multimap_tests.cpp 
79e720040e55de5aa68511d65cacf3952a57081a 
  3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp 
425132e5d7c3770be4a5a39feea5a2f22179b871 
  3rdparty/libprocess/3rdparty/stout/tests/option_tests.cpp 
7ae3b8ffc5df7f8442e72b1a10d50c3f5c373d8c 
  3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 
898d175980e397493270454aafdf340a96c9cf85 
  3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp 
56a63e8f5d809f03c70c60d4f02cc500d06ff96e 
  3rdparty/libprocess/3rdparty/stout/tests/some_tests.cpp 
4041dc47a12c9540dc8d23f083e783e68f0a1af8 
  3rdparty/libprocess/3rdparty/stout/tests/strings_tests.cpp 
b90057972d22123d655697425581cc2767ec825d 

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


Testing (updated)
---

make check
run grep -Hnr "> >" to identify the "> >" occurences


Thanks,

Evelina Dumitrescu

Re: Review Request 26605: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:24 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
37e007e9ee3010d9aacf2de6254abb75b716412d 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
ab609a0d7922298eaf89648200fabd843f8201e0 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
  3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp 
89e77bf75c642c00ac9e0d36a3dbe71838e0efab 
  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
719aa964a536cf02dbd2de440157de487ec703b1 
  3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp 
89340fd79167a311c698740454db19e83c286952 
  3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
ec41fe412290a152a15a49e091f0bc6436e42cfd 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp 
fa1950cc8849fcd81d425c651848e0566078 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/linux.hpp 
7a5573be8d8be537e5fd85b86e322fd5765c54ab 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/ls.hpp 
7cd4a40f57a661d83d1726c65fd8c898072e809b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/osx.hpp 
7d17249cf1d14e9344112dd7fef7230c2ad8 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/pstree.hpp 
e7fe077f763518680ba13d609dba9ea26950210d 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/setns.hpp 
5278996f201a4a3d69282c1bd7b0d230d0f6cd39 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/sysctl.hpp 
a1e6e4d131e15c31135d72399e5e6825e7dd0141 
  3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp 
0004fa5cd249269504155e51e52cd802c0916851 
  3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
3b30ab7ec93a94dc69b4c817a15a16317520fa74 
  3rdparty/libprocess/3rdparty/stout/include/stout/strings.hpp 
01e47ff21574d22f9469ab3bafd458322f6849c9 
  3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
3b60ff824bada441cd657e10ca01762085a6d099 
  3rdparty/libprocess/3rdparty/stout/tests/multimap_tests.cpp 
79e720040e55de5aa68511d65cacf3952a57081a 
  3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp 
425132e5d7c3770be4a5a39feea5a2f22179b871 
  3rdparty/libprocess/3rdparty/stout/tests/option_tests.cpp 
7ae3b8ffc5df7f8442e72b1a10d50c3f5c373d8c 
  3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 
898d175980e397493270454aafdf340a96c9cf85 
  3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp 
56a63e8f5d809f03c70c60d4f02cc500d06ff96e 
  3rdparty/libprocess/3rdparty/stout/tests/some_tests.cpp 
4041dc47a12c9540dc8d23f083e783e68f0a1af8 
  3rdparty/libprocess/3rdparty/stout/tests/strings_tests.cpp 
b90057972d22123d655697425581cc2767ec825d 

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


Testing (updated)
---

make check
run grep -Hnr "> >" to identify the "> >" occurences in stout.
used a script to make the replacements and then checked the file diffs by hand.


Thanks,

Evelina Dumitrescu

Re: Review Request 26605: stout: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:25 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


Summary (updated)
-

stout: Cleanup right angle bracket in the code base.


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


Repository: mesos-git


Description
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
37e007e9ee3010d9aacf2de6254abb75b716412d 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
ab609a0d7922298eaf89648200fabd843f8201e0 
  3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
  3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp 
89e77bf75c642c00ac9e0d36a3dbe71838e0efab 
  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
719aa964a536cf02dbd2de440157de487ec703b1 
  3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp 
89340fd79167a311c698740454db19e83c286952 
  3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
ec41fe412290a152a15a49e091f0bc6436e42cfd 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp 
fa1950cc8849fcd81d425c651848e0566078 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/linux.hpp 
7a5573be8d8be537e5fd85b86e322fd5765c54ab 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/ls.hpp 
7cd4a40f57a661d83d1726c65fd8c898072e809b 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/osx.hpp 
7d17249cf1d14e9344112dd7fef7230c2ad8 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/pstree.hpp 
e7fe077f763518680ba13d609dba9ea26950210d 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/setns.hpp 
5278996f201a4a3d69282c1bd7b0d230d0f6cd39 
  3rdparty/libprocess/3rdparty/stout/include/stout/os/sysctl.hpp 
a1e6e4d131e15c31135d72399e5e6825e7dd0141 
  3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp 
0004fa5cd249269504155e51e52cd802c0916851 
  3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
3b30ab7ec93a94dc69b4c817a15a16317520fa74 
  3rdparty/libprocess/3rdparty/stout/include/stout/strings.hpp 
01e47ff21574d22f9469ab3bafd458322f6849c9 
  3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
3b60ff824bada441cd657e10ca01762085a6d099 
  3rdparty/libprocess/3rdparty/stout/tests/multimap_tests.cpp 
79e720040e55de5aa68511d65cacf3952a57081a 
  3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp 
425132e5d7c3770be4a5a39feea5a2f22179b871 
  3rdparty/libprocess/3rdparty/stout/tests/option_tests.cpp 
7ae3b8ffc5df7f8442e72b1a10d50c3f5c373d8c 
  3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 
898d175980e397493270454aafdf340a96c9cf85 
  3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp 
56a63e8f5d809f03c70c60d4f02cc500d06ff96e 
  3rdparty/libprocess/3rdparty/stout/tests/some_tests.cpp 
4041dc47a12c9540dc8d23f083e783e68f0a1af8 
  3rdparty/libprocess/3rdparty/stout/tests/strings_tests.cpp 
b90057972d22123d655697425581cc2767ec825d 

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


Testing
---

make check
run grep -Hnr "> >" to identify the "> >" occurences in stout.
used a script to make the replacements and then checked the file diffs by hand.


Thanks,

Evelina Dumitrescu

Review Request 26739: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

docs: Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  docs/allocation-module.md bca54b01b80708c8265708aa9e2ef4a02fe64228 

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


Testing
---


Thanks,

Evelina Dumitrescu

Review Request 26740: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

make check
run grep -Hnr "> >" to identify the "> >" occurences in libprocess.
used a script to make the replacements and then checked the file diffs by hand.


Diffs
-

  3rdparty/libprocess/include/process/async.hpp 
9af3cc07334eb7dc26b73964c447cc9b9799396c 
  3rdparty/libprocess/include/process/collect.hpp 
3bee8a6a0b7b48627ebc11c8b950b8582bba2c06 
  3rdparty/libprocess/include/process/defer.hpp 
ebe6f2db47cab2a3306288d8ebabb720e7cd8976 
  3rdparty/libprocess/include/process/delay.hpp 
487f652c9e9b7c8c3aa8b4edc9e59789cffd8da9 
  3rdparty/libprocess/include/process/dispatch.hpp 
bceda2a2ae8963921e8e19660243a8644feab227 
  3rdparty/libprocess/include/process/event.hpp 
294e2158876b25b06456a3619e547082d71e31ed 
  3rdparty/libprocess/include/process/future.hpp 
46ae16b0bbce79005f5ed8711be663eeeb8f4bcf 
  3rdparty/libprocess/include/process/help.hpp 
07e99f1124c60003f4c8b8e6cdcb193bb3577496 
  3rdparty/libprocess/include/process/http.hpp 
9cf05acbb724ab9af8010d1788621d37a0e48e86 
  3rdparty/libprocess/include/process/metrics/metric.hpp 
00ace49bc5ef3914704c6247ece9947960c9 
  3rdparty/libprocess/include/process/metrics/metrics.hpp 
aa44992762927870a5b609df1004027e8bf20eab 
  3rdparty/libprocess/include/process/mutex.hpp 
3ff895510a5fbb06f93f768b1602bafd1eab81a9 
  3rdparty/libprocess/include/process/protobuf.hpp 
f3fc53985847a4c610fd63c91492619f0c6b8720 
  3rdparty/libprocess/include/process/queue.hpp 
0403e251052f2a3f3e89296863acfcf1c08be4fb 
  3rdparty/libprocess/include/process/reap.hpp 
9de5336376b281fd8929c7882ad0feaf69e6de1e 
  3rdparty/libprocess/include/process/run.hpp 
924d31a7d1bba0a6ecd8be8d622a3ae1faebe042 
  3rdparty/libprocess/include/process/sequence.hpp 
d755b3422e8f04072893ef5678954dce828840f8 
  3rdparty/libprocess/include/process/shared.hpp 
572ea2d5dce060193362030524e400641f87ec2e 
  3rdparty/libprocess/include/process/statistics.hpp 
929fb8d544fe83edadbc856efca14177ae30315e 
  3rdparty/libprocess/include/process/subprocess.hpp 
7ff5a10b21889a6ed3b0531731d664f9735196b9 
  3rdparty/libprocess/src/http.cpp 4ef00d11de4ff4e7eb4e44aac204147799f85ac2 
  3rdparty/libprocess/src/httpd.cpp 902ba89b18c5d7edf68ca9d17c55e5727529f96e 
  3rdparty/libprocess/src/metrics/metrics.cpp 
38905d3e920288ac8c18ebed2743ebac9f438d2e 
  3rdparty/libprocess/src/process.cpp 85fb9958342f0bcdde322d9c55333126e6f86668 
  3rdparty/libprocess/src/reap.cpp ac14a868520ececb5fddc6162b0ea9c0f8c35ae3 
  3rdparty/libprocess/src/subprocess.cpp 
b92692388110dbc429dd3a855baa1b5191693e70 
  3rdparty/libprocess/src/tests/http_tests.cpp 
a1c3685c88d268c7ecdc2dad22608198dc0b295d 
  3rdparty/libprocess/src/tests/metrics_tests.cpp 
33539e45bab8f79afa773a325465016f01fd3b75 
  3rdparty/libprocess/src/tests/process_tests.cpp 
b985fb77ea05fae5c0b144ea48814acc7bb5135b 
  3rdparty/libprocess/src/tests/reap_tests.cpp 
a18d54c43fba44d084e722abdc67d32e5d4504e4 
  3rdparty/libprocess/src/tests/shared_tests.cpp 
1df67b4c85d4567cf22922ac339f687832784594 
  3rdparty/libprocess/src/tests/statistics_tests.cpp 
0e4960a4e2e807ee9f3f6d83cdbfa6b563352760 

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


Testing
---


Thanks,

Evelina Dumitrescu

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26736]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26739: docs: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:56 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


Summary (updated)
-

docs: Cleanup right angle bracket in the code base.


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


Repository: mesos-git


Description
---

docs: Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  docs/allocation-module.md bca54b01b80708c8265708aa9e2ef4a02fe64228 

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


Testing
---


Thanks,

Evelina Dumitrescu

Re: Review Request 26739: docs: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:56 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description (updated)
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  docs/allocation-module.md bca54b01b80708c8265708aa9e2ef4a02fe64228 

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


Testing
---


Thanks,

Evelina Dumitrescu

Re: Review Request 26740: libprocess: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:56 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


Summary (updated)
-

libprocess: Cleanup right angle bracket in the code base.


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


Repository: mesos-git


Description
---

make check
run grep -Hnr "> >" to identify the "> >" occurences in libprocess.
used a script to make the replacements and then checked the file diffs by hand.


Diffs
-

  3rdparty/libprocess/include/process/async.hpp 
9af3cc07334eb7dc26b73964c447cc9b9799396c 
  3rdparty/libprocess/include/process/collect.hpp 
3bee8a6a0b7b48627ebc11c8b950b8582bba2c06 
  3rdparty/libprocess/include/process/defer.hpp 
ebe6f2db47cab2a3306288d8ebabb720e7cd8976 
  3rdparty/libprocess/include/process/delay.hpp 
487f652c9e9b7c8c3aa8b4edc9e59789cffd8da9 
  3rdparty/libprocess/include/process/dispatch.hpp 
bceda2a2ae8963921e8e19660243a8644feab227 
  3rdparty/libprocess/include/process/event.hpp 
294e2158876b25b06456a3619e547082d71e31ed 
  3rdparty/libprocess/include/process/future.hpp 
46ae16b0bbce79005f5ed8711be663eeeb8f4bcf 
  3rdparty/libprocess/include/process/help.hpp 
07e99f1124c60003f4c8b8e6cdcb193bb3577496 
  3rdparty/libprocess/include/process/http.hpp 
9cf05acbb724ab9af8010d1788621d37a0e48e86 
  3rdparty/libprocess/include/process/metrics/metric.hpp 
00ace49bc5ef3914704c6247ece9947960c9 
  3rdparty/libprocess/include/process/metrics/metrics.hpp 
aa44992762927870a5b609df1004027e8bf20eab 
  3rdparty/libprocess/include/process/mutex.hpp 
3ff895510a5fbb06f93f768b1602bafd1eab81a9 
  3rdparty/libprocess/include/process/protobuf.hpp 
f3fc53985847a4c610fd63c91492619f0c6b8720 
  3rdparty/libprocess/include/process/queue.hpp 
0403e251052f2a3f3e89296863acfcf1c08be4fb 
  3rdparty/libprocess/include/process/reap.hpp 
9de5336376b281fd8929c7882ad0feaf69e6de1e 
  3rdparty/libprocess/include/process/run.hpp 
924d31a7d1bba0a6ecd8be8d622a3ae1faebe042 
  3rdparty/libprocess/include/process/sequence.hpp 
d755b3422e8f04072893ef5678954dce828840f8 
  3rdparty/libprocess/include/process/shared.hpp 
572ea2d5dce060193362030524e400641f87ec2e 
  3rdparty/libprocess/include/process/statistics.hpp 
929fb8d544fe83edadbc856efca14177ae30315e 
  3rdparty/libprocess/include/process/subprocess.hpp 
7ff5a10b21889a6ed3b0531731d664f9735196b9 
  3rdparty/libprocess/src/http.cpp 4ef00d11de4ff4e7eb4e44aac204147799f85ac2 
  3rdparty/libprocess/src/httpd.cpp 902ba89b18c5d7edf68ca9d17c55e5727529f96e 
  3rdparty/libprocess/src/metrics/metrics.cpp 
38905d3e920288ac8c18ebed2743ebac9f438d2e 
  3rdparty/libprocess/src/process.cpp 85fb9958342f0bcdde322d9c55333126e6f86668 
  3rdparty/libprocess/src/reap.cpp ac14a868520ececb5fddc6162b0ea9c0f8c35ae3 
  3rdparty/libprocess/src/subprocess.cpp 
b92692388110dbc429dd3a855baa1b5191693e70 
  3rdparty/libprocess/src/tests/http_tests.cpp 
a1c3685c88d268c7ecdc2dad22608198dc0b295d 
  3rdparty/libprocess/src/tests/metrics_tests.cpp 
33539e45bab8f79afa773a325465016f01fd3b75 
  3rdparty/libprocess/src/tests/process_tests.cpp 
b985fb77ea05fae5c0b144ea48814acc7bb5135b 
  3rdparty/libprocess/src/tests/reap_tests.cpp 
a18d54c43fba44d084e722abdc67d32e5d4504e4 
  3rdparty/libprocess/src/tests/shared_tests.cpp 
1df67b4c85d4567cf22922ac339f687832784594 
  3rdparty/libprocess/src/tests/statistics_tests.cpp 
0e4960a4e2e807ee9f3f6d83cdbfa6b563352760 

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


Testing
---


Thanks,

Evelina Dumitrescu

Re: Review Request 26740: libprocess: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, 11:57 a.m.)


Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description (updated)
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  3rdparty/libprocess/include/process/async.hpp 
9af3cc07334eb7dc26b73964c447cc9b9799396c 
  3rdparty/libprocess/include/process/collect.hpp 
3bee8a6a0b7b48627ebc11c8b950b8582bba2c06 
  3rdparty/libprocess/include/process/defer.hpp 
ebe6f2db47cab2a3306288d8ebabb720e7cd8976 
  3rdparty/libprocess/include/process/delay.hpp 
487f652c9e9b7c8c3aa8b4edc9e59789cffd8da9 
  3rdparty/libprocess/include/process/dispatch.hpp 
bceda2a2ae8963921e8e19660243a8644feab227 
  3rdparty/libprocess/include/process/event.hpp 
294e2158876b25b06456a3619e547082d71e31ed 
  3rdparty/libprocess/include/process/future.hpp 
46ae16b0bbce79005f5ed8711be663eeeb8f4bcf 
  3rdparty/libprocess/include/process/help.hpp 
07e99f1124c60003f4c8b8e6cdcb193bb3577496 
  3rdparty/libprocess/include/process/http.hpp 
9cf05acbb724ab9af8010d1788621d37a0e48e86 
  3rdparty/libprocess/include/process/metrics/metric.hpp 
00ace49bc5ef3914704c6247ece9947960c9 
  3rdparty/libprocess/include/process/metrics/metrics.hpp 
aa44992762927870a5b609df1004027e8bf20eab 
  3rdparty/libprocess/include/process/mutex.hpp 
3ff895510a5fbb06f93f768b1602bafd1eab81a9 
  3rdparty/libprocess/include/process/protobuf.hpp 
f3fc53985847a4c610fd63c91492619f0c6b8720 
  3rdparty/libprocess/include/process/queue.hpp 
0403e251052f2a3f3e89296863acfcf1c08be4fb 
  3rdparty/libprocess/include/process/reap.hpp 
9de5336376b281fd8929c7882ad0feaf69e6de1e 
  3rdparty/libprocess/include/process/run.hpp 
924d31a7d1bba0a6ecd8be8d622a3ae1faebe042 
  3rdparty/libprocess/include/process/sequence.hpp 
d755b3422e8f04072893ef5678954dce828840f8 
  3rdparty/libprocess/include/process/shared.hpp 
572ea2d5dce060193362030524e400641f87ec2e 
  3rdparty/libprocess/include/process/statistics.hpp 
929fb8d544fe83edadbc856efca14177ae30315e 
  3rdparty/libprocess/include/process/subprocess.hpp 
7ff5a10b21889a6ed3b0531731d664f9735196b9 
  3rdparty/libprocess/src/http.cpp 4ef00d11de4ff4e7eb4e44aac204147799f85ac2 
  3rdparty/libprocess/src/httpd.cpp 902ba89b18c5d7edf68ca9d17c55e5727529f96e 
  3rdparty/libprocess/src/metrics/metrics.cpp 
38905d3e920288ac8c18ebed2743ebac9f438d2e 
  3rdparty/libprocess/src/process.cpp 85fb9958342f0bcdde322d9c55333126e6f86668 
  3rdparty/libprocess/src/reap.cpp ac14a868520ececb5fddc6162b0ea9c0f8c35ae3 
  3rdparty/libprocess/src/subprocess.cpp 
b92692388110dbc429dd3a855baa1b5191693e70 
  3rdparty/libprocess/src/tests/http_tests.cpp 
a1c3685c88d268c7ecdc2dad22608198dc0b295d 
  3rdparty/libprocess/src/tests/metrics_tests.cpp 
33539e45bab8f79afa773a325465016f01fd3b75 
  3rdparty/libprocess/src/tests/process_tests.cpp 
b985fb77ea05fae5c0b144ea48814acc7bb5135b 
  3rdparty/libprocess/src/tests/reap_tests.cpp 
a18d54c43fba44d084e722abdc67d32e5d4504e4 
  3rdparty/libprocess/src/tests/shared_tests.cpp 
1df67b4c85d4567cf22922ac339f687832784594 
  3rdparty/libprocess/src/tests/statistics_tests.cpp 
0e4960a4e2e807ee9f3f6d83cdbfa6b563352760 

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


Testing (updated)
---

make check
run grep -Hnr "> >" to identify the "> >" occurences in libprocess.
used a script to make the replacements and then checked the file diffs by hand.


Thanks,

Evelina Dumitrescu

Review Request 26741: mesos: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  src/authorizer/authorizer.hpp c039d9412780aa199db169b31991bf9f45b07d0f 
  src/authorizer/authorizer.cpp 21e97e315478a4ca9442af83732665f85eb2f8fc 
  src/cli/mesos.cpp 171a707cd2ba2348898e7fbe8fe9f0634edd6d86 
  src/cli/resolve.cpp a99b6094dffc9f7aa44bcf63ad40121e1abb120b 
  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/files/files.cpp 12e8f75aa7bd77d2e81d5d3a7a4d09dd915854aa 
  src/health-check/main.cpp a4ce742ab8deff1ebd99359112670493fdaeeac3 
  src/java/jni/org_apache_mesos_Log.cpp 
1e1d821dcbecdc1e1e5cdf38e6c6aa61ab501075 
  src/java/jni/org_apache_mesos_state_AbstractState.cpp 
1accc8a498a68b7cfd9e39dc1f3ce01c8bfd219f 
  src/launcher/executor.cpp cbc8750a4d182251e6c15da6c7e75443d8c110bb 
  src/linux/cgroups.hpp abf31df1b4dbf6f715f93256b83c9996a45099cf 
  src/linux/cgroups.cpp 62df4b7645c6ab061a47634058d79ca849caa6b9 
  src/linux/perf.hpp dd9299c91106ed514a6e5f69053aba112e726652 
  src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
  src/linux/routing/diagnosis/diagnosis.hpp 
91618415d25e22422267f64ede972456b0de387a 
  src/linux/routing/diagnosis/diagnosis.cpp 
d826ae240901eff1d49febacb287cebd6e6724c9 
  src/linux/routing/filter/filter.hpp a603d73709f2a81311609a98ca61c734150ebe25 
  src/linux/routing/filter/icmp.hpp dc075a7c2643d85c81355de8ce8fbf43addbd056 
  src/linux/routing/filter/icmp.cpp 12b9eb75135602ee6d4caa92ad7275f266d742eb 
  src/linux/routing/filter/internal.hpp 
a970613ce1a9da76388a49caf5409ed73a457367 
  src/linux/routing/filter/ip.hpp 566fd1e06837ec6ea696483627e37de98d5a8a1d 
  src/linux/routing/filter/ip.cpp 74525a9e6be8c96cda0940011d7cd930876e0394 
  src/linux/routing/internal.hpp 87a539b5d9e46671261b710281aff8aa82e315b4 
  src/linux/routing/link/internal.hpp 0d46e9a6901c79514bd83c27a89c83407f356578 
  src/linux/routing/link/link.hpp 7e5b79e3fa74e4c2f43b622a569d3b9dc62f2eb9 
  src/linux/routing/link/link.cpp a912122672833f2cc646706f0711220b35b9ac9f 
  src/linux/routing/queueing/internal.hpp 
4d8bd55096df9192e5656c899c537ac3bd45b7d9 
  src/linux/routing/route.hpp f443e06f7bdb39215faa3b10a30310360552ffcc 
  src/linux/routing/route.cpp 80860346066b67a33f6ec75e961391e07f89e500 
  src/local/local.cpp 66de798377269150a2e546daa5ca7c5371bbce79 
  src/log/consensus.cpp 59f80d02d1d3c11683631f3fc5f6e923b5ebdf96 
  src/log/coordinator.hpp b8a475fa31a4464006f1cde506cc6f6534492448 
  src/log/coordinator.cpp fe0c5f9c55fd7a19b9c85a0860f88dd14205a631 
  src/log/log.hpp 7c905c7e431b6663af8cdbce94d98c905da878ae 
  src/log/log.cpp b3c6c20d734ea82d8531217d53decf1707183565 
  src/log/main.cpp 348e887e8559f8d062dfe004f6bf8b07289e537c 
  src/log/network.hpp 7c74a55cc2a71fa2acd207605f972e7fbd203be4 
  src/log/recover.hpp 6243c184ea7e86d1a682c0cc01d73eb375910316 
  src/log/recover.cpp 2013e9193fc53c769ec6815d769cdf8a565a8c5c 
  src/log/replica.hpp 33d3f1d9e89035936c67739898e73a06b391fcd0 
  src/log/replica.cpp c18de86f2659b848b0e8f0468e4efa820d048970 
  src/log/tool/benchmark.cpp 54d7898d048185c024cf63ce1869509823c9b7fa 
  src/log/tool/read.cpp d14138502f5bc9a725deb83da505765865da017f 
  src/master/allocator.hpp 02d20d0cc802805bc702891306aa42894531b223 
  src/master/contender.hpp 76beb5f973ae02507849233b6d73c43293669489 
  src/master/contender.cpp c1bf82b621d6b46afe001acafe9ee53336726406 
  src/master/detector.hpp 2905e2b3536e14e9df3570da172603e6ed81aae1 
  src/master/detector.cpp 700eb9dde8e71648bacc00a82766634f77cf2d15 
  src/master/hierarchical_allocator_process.hpp 
31dfb2cc86e2e74da43f05fbada10976ce65f3e4 
  src/master/main.cpp 72e243a7374be36787a1e5a87d1ff370b8b9d4e0 
  src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
  src/master/master.cpp 1b1ce0de3065ced45890777d42c69ef1091f5699 
  src/master/registrar.cpp 0831963e01e3c87bf0ac27af24b832ab2ae09d97 
  src/module/manager.hpp 797728a8c8e88dd1a13142a355cbe0b1491fb7a2 
  src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
  src/sasl/authenticator.hpp 6f4d3dbeba4d2df68e3b6ed82e6670ebb30c0c63 
  src/sasl/auxprop.hpp 44e201b039eb5684f0184087decdc23c3fa1dc75 
  src/sasl/auxprop.cpp 6de12229d16f616bc3807e54041e24900e703491 
  src/sched/sched.cpp a37ed3d2e11035650b9bf0440fb87f9129d8 
  src/scheduler/scheduler.cpp fb88a3e029e97ba33eae5d50503be5ed9c9533e6 
  src/slave/containerizer/composing.hpp 
f1e60b0dae45757f3573c81a4a4a2de6fcb27aca 
  src/slave/containerizer/composing.cpp 
9022700b628d9746a6a8a17c9fbf1b1988da6fca 
  src/slave/containerizer/containerizer.hpp 
8a6641269b8e0

Re: Review Request 26741: mesos: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

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

(Updated Oct. 15, 2014, noon)


Review request for mesos, Jie Yu and Till Toenshoff.


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


Repository: mesos-git


Description
---

Replaced > > with >> to be consistent with the C++ 11 standarad.


Diffs
-

  src/authorizer/authorizer.hpp c039d9412780aa199db169b31991bf9f45b07d0f 
  src/authorizer/authorizer.cpp 21e97e315478a4ca9442af83732665f85eb2f8fc 
  src/cli/mesos.cpp 171a707cd2ba2348898e7fbe8fe9f0634edd6d86 
  src/cli/resolve.cpp a99b6094dffc9f7aa44bcf63ad40121e1abb120b 
  src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/files/files.cpp 12e8f75aa7bd77d2e81d5d3a7a4d09dd915854aa 
  src/health-check/main.cpp a4ce742ab8deff1ebd99359112670493fdaeeac3 
  src/java/jni/org_apache_mesos_Log.cpp 
1e1d821dcbecdc1e1e5cdf38e6c6aa61ab501075 
  src/java/jni/org_apache_mesos_state_AbstractState.cpp 
1accc8a498a68b7cfd9e39dc1f3ce01c8bfd219f 
  src/launcher/executor.cpp cbc8750a4d182251e6c15da6c7e75443d8c110bb 
  src/linux/cgroups.hpp abf31df1b4dbf6f715f93256b83c9996a45099cf 
  src/linux/cgroups.cpp 62df4b7645c6ab061a47634058d79ca849caa6b9 
  src/linux/perf.hpp dd9299c91106ed514a6e5f69053aba112e726652 
  src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
  src/linux/routing/diagnosis/diagnosis.hpp 
91618415d25e22422267f64ede972456b0de387a 
  src/linux/routing/diagnosis/diagnosis.cpp 
d826ae240901eff1d49febacb287cebd6e6724c9 
  src/linux/routing/filter/filter.hpp a603d73709f2a81311609a98ca61c734150ebe25 
  src/linux/routing/filter/icmp.hpp dc075a7c2643d85c81355de8ce8fbf43addbd056 
  src/linux/routing/filter/icmp.cpp 12b9eb75135602ee6d4caa92ad7275f266d742eb 
  src/linux/routing/filter/internal.hpp 
a970613ce1a9da76388a49caf5409ed73a457367 
  src/linux/routing/filter/ip.hpp 566fd1e06837ec6ea696483627e37de98d5a8a1d 
  src/linux/routing/filter/ip.cpp 74525a9e6be8c96cda0940011d7cd930876e0394 
  src/linux/routing/internal.hpp 87a539b5d9e46671261b710281aff8aa82e315b4 
  src/linux/routing/link/internal.hpp 0d46e9a6901c79514bd83c27a89c83407f356578 
  src/linux/routing/link/link.hpp 7e5b79e3fa74e4c2f43b622a569d3b9dc62f2eb9 
  src/linux/routing/link/link.cpp a912122672833f2cc646706f0711220b35b9ac9f 
  src/linux/routing/queueing/internal.hpp 
4d8bd55096df9192e5656c899c537ac3bd45b7d9 
  src/linux/routing/route.hpp f443e06f7bdb39215faa3b10a30310360552ffcc 
  src/linux/routing/route.cpp 80860346066b67a33f6ec75e961391e07f89e500 
  src/local/local.cpp 66de798377269150a2e546daa5ca7c5371bbce79 
  src/log/consensus.cpp 59f80d02d1d3c11683631f3fc5f6e923b5ebdf96 
  src/log/coordinator.hpp b8a475fa31a4464006f1cde506cc6f6534492448 
  src/log/coordinator.cpp fe0c5f9c55fd7a19b9c85a0860f88dd14205a631 
  src/log/log.hpp 7c905c7e431b6663af8cdbce94d98c905da878ae 
  src/log/log.cpp b3c6c20d734ea82d8531217d53decf1707183565 
  src/log/main.cpp 348e887e8559f8d062dfe004f6bf8b07289e537c 
  src/log/network.hpp 7c74a55cc2a71fa2acd207605f972e7fbd203be4 
  src/log/recover.hpp 6243c184ea7e86d1a682c0cc01d73eb375910316 
  src/log/recover.cpp 2013e9193fc53c769ec6815d769cdf8a565a8c5c 
  src/log/replica.hpp 33d3f1d9e89035936c67739898e73a06b391fcd0 
  src/log/replica.cpp c18de86f2659b848b0e8f0468e4efa820d048970 
  src/log/tool/benchmark.cpp 54d7898d048185c024cf63ce1869509823c9b7fa 
  src/log/tool/read.cpp d14138502f5bc9a725deb83da505765865da017f 
  src/master/allocator.hpp 02d20d0cc802805bc702891306aa42894531b223 
  src/master/contender.hpp 76beb5f973ae02507849233b6d73c43293669489 
  src/master/contender.cpp c1bf82b621d6b46afe001acafe9ee53336726406 
  src/master/detector.hpp 2905e2b3536e14e9df3570da172603e6ed81aae1 
  src/master/detector.cpp 700eb9dde8e71648bacc00a82766634f77cf2d15 
  src/master/hierarchical_allocator_process.hpp 
31dfb2cc86e2e74da43f05fbada10976ce65f3e4 
  src/master/main.cpp 72e243a7374be36787a1e5a87d1ff370b8b9d4e0 
  src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
  src/master/master.cpp 1b1ce0de3065ced45890777d42c69ef1091f5699 
  src/master/registrar.cpp 0831963e01e3c87bf0ac27af24b832ab2ae09d97 
  src/module/manager.hpp 797728a8c8e88dd1a13142a355cbe0b1491fb7a2 
  src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
  src/sasl/authenticator.hpp 6f4d3dbeba4d2df68e3b6ed82e6670ebb30c0c63 
  src/sasl/auxprop.hpp 44e201b039eb5684f0184087decdc23c3fa1dc75 
  src/sasl/auxprop.cpp 6de12229d16f616bc3807e54041e24900e703491 
  src/sched/sched.cpp a37ed3d2e11035650b9bf0440fb87f9129d8 
  src/scheduler/scheduler.cpp fb88a3e029e97ba33eae5d50503be5ed9c9533e6 
  src/slave/containerizer/composing.hpp 
f1e60b0dae45757f3573c81a4a4a2de6fcb27aca 
  src/slave/containerizer/composing.cpp 
9022700b628d9746a6a8a17c9fbf1b1988da6fca 
  src/slave/containerizer/

Re: Review Request 26605: stout: Cleanup right angle bracket in the code base.

[Evelina Dumitrescu]

> On Oct. 13, 2014, 9:17 a.m., Till Toenshoff wrote:
> > Thanks for proposing this patch Evelina.
> > 
> > Could you please split this into seperate patches for stout, libprocess and 
> > mesos itself?
> 
> Evelina Dumitrescu wrote:
> What do you mean by three separate patches? I suppose three different 
> commits ...
> It is not very clear to me how to organize them. As far as I can see 
> stout is included in libprocess.
> 
> Till Toenshoff wrote:
> Yes, three different review proposals / aka patches.

Done


- Evelina


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


On Oct. 15, 2014, 11:25 a.m., Evelina Dumitrescu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26605/
> ---
> 
> (Updated Oct. 15, 2014, 11:25 a.m.)
> 
> 
> Review request for mesos, Jie Yu and Till Toenshoff.
> 
> 
> Bugs: MESOS-1872
> https://issues.apache.org/jira/browse/MESOS-1872
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Replaced > > with >> to be consistent with the C++ 11 standarad.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/cache.hpp 
> 37e007e9ee3010d9aacf2de6254abb75b716412d 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags.hpp 
> ab609a0d7922298eaf89648200fabd843f8201e0 
>   3rdparty/libprocess/3rdparty/stout/include/stout/flags/flags.hpp 
> f4b7a95a8ca1e625c3dac7823f4db47f7b4f2c10 
>   3rdparty/libprocess/3rdparty/stout/include/stout/interval.hpp 
> 89e77bf75c642c00ac9e0d36a3dbe71838e0efab 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 719aa964a536cf02dbd2de440157de487ec703b1 
>   3rdparty/libprocess/3rdparty/stout/include/stout/linkedhashmap.hpp 
> 89340fd79167a311c698740454db19e83c286952 
>   3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
> ec41fe412290a152a15a49e091f0bc6436e42cfd 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/killtree.hpp 
> fa1950cc8849fcd81d425c651848e0566078 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/linux.hpp 
> 7a5573be8d8be537e5fd85b86e322fd5765c54ab 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/ls.hpp 
> 7cd4a40f57a661d83d1726c65fd8c898072e809b 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/osx.hpp 
> 7d17249cf1d14e9344112dd7fef7230c2ad8 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/pstree.hpp 
> e7fe077f763518680ba13d609dba9ea26950210d 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/setns.hpp 
> 5278996f201a4a3d69282c1bd7b0d230d0f6cd39 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os/sysctl.hpp 
> a1e6e4d131e15c31135d72399e5e6825e7dd0141 
>   3rdparty/libprocess/3rdparty/stout/include/stout/proc.hpp 
> 0004fa5cd249269504155e51e52cd802c0916851 
>   3rdparty/libprocess/3rdparty/stout/include/stout/protobuf.hpp 
> 3b30ab7ec93a94dc69b4c817a15a16317520fa74 
>   3rdparty/libprocess/3rdparty/stout/include/stout/strings.hpp 
> 01e47ff21574d22f9469ab3bafd458322f6849c9 
>   3rdparty/libprocess/3rdparty/stout/tests/flags_tests.cpp 
> 3b60ff824bada441cd657e10ca01762085a6d099 
>   3rdparty/libprocess/3rdparty/stout/tests/multimap_tests.cpp 
> 79e720040e55de5aa68511d65cacf3952a57081a 
>   3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp 
> 425132e5d7c3770be4a5a39feea5a2f22179b871 
>   3rdparty/libprocess/3rdparty/stout/tests/option_tests.cpp 
> 7ae3b8ffc5df7f8442e72b1a10d50c3f5c373d8c 
>   3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 
> 898d175980e397493270454aafdf340a96c9cf85 
>   3rdparty/libprocess/3rdparty/stout/tests/proc_tests.cpp 
> 56a63e8f5d809f03c70c60d4f02cc500d06ff96e 
>   3rdparty/libprocess/3rdparty/stout/tests/some_tests.cpp 
> 4041dc47a12c9540dc8d23f083e783e68f0a1af8 
>   3rdparty/libprocess/3rdparty/stout/tests/strings_tests.cpp 
> b90057972d22123d655697425581cc2767ec825d 
> 
> Diff: https://reviews.apache.org/r/26605/diff/
> 
> 
> Testing
> ---
> 
> make check
> run grep -Hnr "> >" to identify the "> >" occurences in stout.
> used a script to make the replacements and then checked the file diffs by 
> hand.
> 
> 
> Thanks,
> 
> Evelina Dumitrescu
> 
>

Re: Review Request 26229: Expose poll interval from the reaper.

[Alexander Rukletsov]

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

(Updated Oct. 15, 2014, 12:21 p.m.)


Review request for mesos, Benjamin Hindman, Ben Mahler, Ian Downes, Jie Yu, and 
Till Toenshoff.


Changes
---

Rename funcations; expose only maximal interval.


Repository: mesos-git


Description
---

Lower and upper bounds for the poll interval are refactored as static functions 
visible to outer world.


Diffs (updated)
-

  3rdparty/libprocess/include/process/reap.hpp 
9de5336376b281fd8929c7882ad0feaf69e6de1e 
  3rdparty/libprocess/src/reap.cpp ac14a868520ececb5fddc6162b0ea9c0f8c35ae3 

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


Testing
---

make check (Mac OS 10.9.4, Ubuntu 14.04)


Thanks,

Alexander Rukletsov

Re: Review Request 26426: Add --enable-debug flag to ./configure for controlling emission of debug information

[Timothy St. Clair]

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

Ship it!


I'll wait a couple of days for any more comments before a push.

- Timothy St. Clair


On Oct. 14, 2014, 11:07 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26426/
> ---
> 
> (Updated Oct. 14, 2014, 11:07 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Timothy St. Clair.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Reworks building mesos in "debug" vs. "release". By default, mesos is now 
> built in release (no debug info, optimized build). If '--enable-debug' is 
> specified to configure, than optimization will be turned off, and debug info 
> will be turned on.
> 
> This also adds a variable 'DEBUG' to the build environment, which people can 
> use in code to see if mesos is built with debugging to enable extra 
> assertions / checks. For release builds we may want to set 'NDEBUG' which 
> removes assert()'s, but that is a seperate discussion.
> 
> Main benefits:
> 1) Getting a build to include/exclude debug information at will is feasible. 
> Before some things like using clang would forcibly enable debug info in all 
> cases
> 2) libmesos.so and the other binaries which get packaged up for use in 
> distributions shrink considerably without manually stripping post-build 
> (Improves build time, makes packaging cleaner)
> 
> 
> Diffs
> -
> 
>   configure.ac 2b372e06006250b5230956ef096473e98f3fa590 
> 
> Diff: https://reviews.apache.org/r/26426/diff/
> 
> 
> Testing
> ---
> 
> Built with both --enable-debug and without, checking that the flags get 
> passed through correctly.
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 26741: mesos: Cleanup right angle bracket in the code base.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26605, 26740, 26739, 26741]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, noon, Evelina Dumitrescu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26741/
> ---
> 
> (Updated Oct. 15, 2014, noon)
> 
> 
> Review request for mesos, Jie Yu and Till Toenshoff.
> 
> 
> Bugs: MESOS-1872
> https://issues.apache.org/jira/browse/MESOS-1872
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Replaced > > with >> to be consistent with the C++ 11 standarad.
> 
> 
> Diffs
> -
> 
>   src/authorizer/authorizer.hpp c039d9412780aa199db169b31991bf9f45b07d0f 
>   src/authorizer/authorizer.cpp 21e97e315478a4ca9442af83732665f85eb2f8fc 
>   src/cli/mesos.cpp 171a707cd2ba2348898e7fbe8fe9f0634edd6d86 
>   src/cli/resolve.cpp a99b6094dffc9f7aa44bcf63ad40121e1abb120b 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/files/files.cpp 12e8f75aa7bd77d2e81d5d3a7a4d09dd915854aa 
>   src/health-check/main.cpp a4ce742ab8deff1ebd99359112670493fdaeeac3 
>   src/java/jni/org_apache_mesos_Log.cpp 
> 1e1d821dcbecdc1e1e5cdf38e6c6aa61ab501075 
>   src/java/jni/org_apache_mesos_state_AbstractState.cpp 
> 1accc8a498a68b7cfd9e39dc1f3ce01c8bfd219f 
>   src/launcher/executor.cpp cbc8750a4d182251e6c15da6c7e75443d8c110bb 
>   src/linux/cgroups.hpp abf31df1b4dbf6f715f93256b83c9996a45099cf 
>   src/linux/cgroups.cpp 62df4b7645c6ab061a47634058d79ca849caa6b9 
>   src/linux/perf.hpp dd9299c91106ed514a6e5f69053aba112e726652 
>   src/linux/perf.cpp 863aa4a972289a59f57e93cd06ba2bf9df949fe2 
>   src/linux/routing/diagnosis/diagnosis.hpp 
> 91618415d25e22422267f64ede972456b0de387a 
>   src/linux/routing/diagnosis/diagnosis.cpp 
> d826ae240901eff1d49febacb287cebd6e6724c9 
>   src/linux/routing/filter/filter.hpp 
> a603d73709f2a81311609a98ca61c734150ebe25 
>   src/linux/routing/filter/icmp.hpp dc075a7c2643d85c81355de8ce8fbf43addbd056 
>   src/linux/routing/filter/icmp.cpp 12b9eb75135602ee6d4caa92ad7275f266d742eb 
>   src/linux/routing/filter/internal.hpp 
> a970613ce1a9da76388a49caf5409ed73a457367 
>   src/linux/routing/filter/ip.hpp 566fd1e06837ec6ea696483627e37de98d5a8a1d 
>   src/linux/routing/filter/ip.cpp 74525a9e6be8c96cda0940011d7cd930876e0394 
>   src/linux/routing/internal.hpp 87a539b5d9e46671261b710281aff8aa82e315b4 
>   src/linux/routing/link/internal.hpp 
> 0d46e9a6901c79514bd83c27a89c83407f356578 
>   src/linux/routing/link/link.hpp 7e5b79e3fa74e4c2f43b622a569d3b9dc62f2eb9 
>   src/linux/routing/link/link.cpp a912122672833f2cc646706f0711220b35b9ac9f 
>   src/linux/routing/queueing/internal.hpp 
> 4d8bd55096df9192e5656c899c537ac3bd45b7d9 
>   src/linux/routing/route.hpp f443e06f7bdb39215faa3b10a30310360552ffcc 
>   src/linux/routing/route.cpp 80860346066b67a33f6ec75e961391e07f89e500 
>   src/local/local.cpp 66de798377269150a2e546daa5ca7c5371bbce79 
>   src/log/consensus.cpp 59f80d02d1d3c11683631f3fc5f6e923b5ebdf96 
>   src/log/coordinator.hpp b8a475fa31a4464006f1cde506cc6f6534492448 
>   src/log/coordinator.cpp fe0c5f9c55fd7a19b9c85a0860f88dd14205a631 
>   src/log/log.hpp 7c905c7e431b6663af8cdbce94d98c905da878ae 
>   src/log/log.cpp b3c6c20d734ea82d8531217d53decf1707183565 
>   src/log/main.cpp 348e887e8559f8d062dfe004f6bf8b07289e537c 
>   src/log/network.hpp 7c74a55cc2a71fa2acd207605f972e7fbd203be4 
>   src/log/recover.hpp 6243c184ea7e86d1a682c0cc01d73eb375910316 
>   src/log/recover.cpp 2013e9193fc53c769ec6815d769cdf8a565a8c5c 
>   src/log/replica.hpp 33d3f1d9e89035936c67739898e73a06b391fcd0 
>   src/log/replica.cpp c18de86f2659b848b0e8f0468e4efa820d048970 
>   src/log/tool/benchmark.cpp 54d7898d048185c024cf63ce1869509823c9b7fa 
>   src/log/tool/read.cpp d14138502f5bc9a725deb83da505765865da017f 
>   src/master/allocator.hpp 02d20d0cc802805bc702891306aa42894531b223 
>   src/master/contender.hpp 76beb5f973ae02507849233b6d73c43293669489 
>   src/master/contender.cpp c1bf82b621d6b46afe001acafe9ee53336726406 
>   src/master/detector.hpp 2905e2b3536e14e9df3570da172603e6ed81aae1 
>   src/master/detector.cpp 700eb9dde8e71648bacc00a82766634f77cf2d15 
>   src/master/hierarchical_allocator_process.hpp 
> 31dfb2cc86e2e74da43f05fbada10976ce65f3e4 
>   src/master/main.cpp 72e243a7374be36787a1e5a87d1ff370b8b9d4e0 
>   src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
>   src/master/master.cpp 1b1ce0de3065ced45890777d42c69ef1091f5699 
>   src/master/registrar.cpp 0831963e01e3c87bf0ac27af24b832ab2ae09d97 
>   src/module/manager.hpp 797728a8c8e88dd1a13142a355cbe0b1491fb7a2 
>   src/module/manager.

Re: Review Request 26229: Expose poll interval from the reaper.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26229]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 12:21 p.m., Alexander Rukletsov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26229/
> ---
> 
> (Updated Oct. 15, 2014, 12:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Ben Mahler, Ian Downes, Jie Yu, 
> and Till Toenshoff.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Lower and upper bounds for the poll interval are refactored as static 
> functions visible to outer world.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/reap.hpp 
> 9de5336376b281fd8929c7882ad0feaf69e6de1e 
>   3rdparty/libprocess/src/reap.cpp ac14a868520ececb5fddc6162b0ea9c0f8c35ae3 
> 
> Diff: https://reviews.apache.org/r/26229/diff/
> 
> 
> Testing
> ---
> 
> make check (Mac OS 10.9.4, Ubuntu 14.04)
> 
> 
> Thanks,
> 
> Alexander Rukletsov
> 
>

FW: Project report summary - Meeting of October 15, 2014

[Chris Mattmann]

Hi Mesos folks,

As of now, we still don¹t have a board report for your
project.


Cheers,
Chris

-Original Message-
From: "chair...@apache.org" 
Reply-To: "bo...@apache.org" 
Date: Wednesday, October 15, 2014 at 5:40 AM
To: "bo...@apache.org" 
Subject: Project report summary - Meeting of October 15, 2014

>The next meeting of the Board of Directors will occur on October 15, 2014.
>The current agenda can be viewed at:
>
>  https://whimsy.apache.org/board/agenda/2014-10-15
>
>The meeting is scheduled for 10:30am Pacific and will begin as
>soon thereafter that a sufficient attendance to constitute a
>quorum is recognized by the chairman.
>
>Other Time Zones: http://timeanddate.com/s/2qxk
>
>The meeting will be held via teleconference, hosted by Doug Cutting and
>Cloudera:
>
>International   : +1-650-479-3208
>U.S. Toll-Free  : +1-877-668-4493
>Other Toll-Free : http://s.apache.org/globalcallin
>Access Code : 2329 5771
>
>IRC #asfboard on irc.freenode.net will be used for backup
>purposes.
>
>Missing Project Reports
>---
>
>The following projects have not yet submitted a report:
>  - Mesos
>  - OpenMeetings
>  - Perl
>  - TomEE
>
>Summaries of Submitted Project Reports
>--
>
>Accumulo
>
>  The Apache Accumulo sorted, distributed key/value store is a robust,
>  scalable, high performance data storage system that features cell-based
>  access control and customizable server-side processing.  It is based on
>  Google's BigTable design and is built on top of Apache Hadoop,
>  Zookeeper, and Thrift.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Accumulo
>
>ACE
>
>  Apache ACE is a software distribution framework that allows you to
>  centrally manage and distribute modular software components,
>  configuration data and other artifacts to OSGi based and related target
>  systems.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/ACE
>
>ActiveMQ
>
>  Apache ActiveMQ is a popular and powerful open source messaging
>  server. Apache ActiveMQ is fast, supports many Cross Language Clients
>  and Protocols, comes with easy to use Enterprise Integration Patterns
>  and many advanced features while fully supporting JMS 1.1 and J2EE
>  1.4.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/ActiveMQ
>
>Airavata
>
>  Apache Airavata is a software framework to construct, execute, and
>manage 
>  long running applications and workflows on distributed computing
>resources.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Airavata
>
>Aries
>
>  Apache Aries delivers a set of pluggable Java components enabling an
>  enterprise OSGi application programming model.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Aries
>
>Attic
>
>  A quiet quarter - one ticket on helping the WS/Axis TLP retire three of
>  their subprojects is all the activity that has been required of the
>Attic.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Attic
>
>  Comments:
>cm: please add the year too regarding last PMC/committer addition.
>Thanks!
>
>Avro
>
>  Apache Avro is a cross-language data serialization system.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Avro
>
>Axis
>
>  The Apache Axis project is responsible for the creation and maintenance
>of
>  software related to the Axis Web Services frameworks and subsidiary
>  components.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Axis
>
>  Comments:
>cm: Please list dates of last PMC/committer addition. Thanks!
>
>Celix
>
>  Celix is an OSGi like implementation in C with a distinct focus on
>  interoperability between Java and C.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Celix
>
>Chukwa
>
>  Apache Chukwa is a log collection and analysis framework for Apache
>Hadoop
>  Clusters.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Chukwa
>
>Crunch
>
>  Apache Crunch is a Java library for writing, testing, and running
>MapReduce
>  and Spark pipelines on Apache Hadoop.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/Crunch
>
>CXF
>
>  Apache CXF is an open source services framework. CXF helps you build and
>  develop services using frontend programming APIs, like JAX-WS and
>  JAX-RS. These services can speak a variety of protocols such as SOAP,
>  XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports
>  such as HTTP, JMS or JBI.
>
>  - https://whimsy.apache.org/board/agenda/2014-10-15/CXF
>
>  Comments:
>cm: Please list dates of last PMC/committer addition. Thanks!
>
>DB
>
>  The Apache DB TLP consists of the following subprojects:
>   o DdlUtils : a small, easy-to-use component for working with
>Database Definition (DDL) files.
>   o Derby: an open source relational database implemented entirely
>in Java.
>   o JDO  : focused on building the API and the TCK for compatibility
>
>  - https://whimsy.apache.org/board/agenda/2014-10-1

Re: Review Request 26071: Sample isolator module.

[Kapil Arya]

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

(Updated Oct. 15, 2014, 11:50 a.m.)


Review request for mesos, Bernd Mathiske, Ian Downes, and Niklas Nielsen.


Changes
---

Updated Isolator tests to run with example Isolator modules as well.


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


Repository: mesos-git


Description (updated)
---

Created CPU and Memory isolation modules based on Posix CPU/Memory Isolators.  
These modules are also hooked up to the relevant Isolator tests using the typed 
test mechanism.  It also paves the way for future integration with custom 
modules specified on the command line.


Diffs (updated)
-

  src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
  src/examples/test_isolator_module.cpp PRE-CREATION 
  src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
  src/slave/containerizer/isolator.hpp e52e8b15c740c62ef64b49897d3d6ae5179d4719 
  src/slave/containerizer/isolators/posix.hpp 
f120aafef96343d84f93c5636484509dc972a0a8 
  src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
  src/tests/module.hpp PRE-CREATION 
  src/tests/module.cpp PRE-CREATION 

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


Testing
---

make check with an  Isolator module test.


Thanks,

Kapil Arya

Re: Review Request 26071: Sample isolator module.

[Kapil Arya]

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

(Updated Oct. 15, 2014, 11:50 a.m.)


Review request for mesos, Bernd Mathiske, Ian Downes, and Niklas Nielsen.


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


Repository: mesos-git


Description
---

Created CPU and Memory isolation modules based on Posix CPU/Memory Isolators.  
These modules are also hooked up to the relevant Isolator tests using the typed 
test mechanism.  It also paves the way for future integration with custom 
modules specified on the command line.


Diffs
-

  src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
  src/examples/test_isolator_module.cpp PRE-CREATION 
  src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
  src/slave/containerizer/isolator.hpp e52e8b15c740c62ef64b49897d3d6ae5179d4719 
  src/slave/containerizer/isolators/posix.hpp 
f120aafef96343d84f93c5636484509dc972a0a8 
  src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
  src/tests/module.hpp PRE-CREATION 
  src/tests/module.cpp PRE-CREATION 

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


Testing
---

make check with an  Isolator module test.


Thanks,

Kapil Arya

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Timothy Chen]

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



src/docker/docker.cpp


Print the timeout value as well.



src/docker/docker.cpp


You can use our to_string method (stringify) instead.



src/docker/docker.cpp


Also, have you tried with the docker cli what's the exit status when you 
run docker stop if either 1) docker succesffully stopped 2) docker killed it in 
the end 3) can't do both



src/docker/docker.cpp


Does docker stop -t 0 doesn't do this for you?



src/slave/containerizer/docker.cpp


You can just pass the duration value in.



src/slave/flags.hpp


You're storing this as a duration type, so it actually takes a duration 
string instead of a number of seconds integer right?


- Timothy Chen


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26724: Remove --without-cxx11 flag

[Cody Maloney]

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

(Updated Oct. 15, 2014, 4:49 p.m.)


Review request for mesos and Dominic Hamon.


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


Repository: mesos-git


Description
---

C++11 is required now. Specifying this flag makes no change in the actual 
compilation of mesos.


Diffs
-

  configure.ac 2b372e06006250b5230956ef096473e98f3fa590 

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


Testing
---

grep -r 'with_cxx11' in the mesos repository


Thanks,

Cody Maloney

Re: Review Request 26724: Remove --without-cxx11 flag

[Dominic Hamon]

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

Ship it!


Ship It!

- Dominic Hamon


On Oct. 15, 2014, 9:49 a.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26724/
> ---
> 
> (Updated Oct. 15, 2014, 9:49 a.m.)
> 
> 
> Review request for mesos and Dominic Hamon.
> 
> 
> Bugs: MESOS-750
> https://issues.apache.org/jira/browse/MESOS-750
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> C++11 is required now. Specifying this flag makes no change in the actual 
> compilation of mesos.
> 
> 
> Diffs
> -
> 
>   configure.ac 2b372e06006250b5230956ef096473e98f3fa590 
> 
> Diff: https://reviews.apache.org/r/26724/diff/
> 
> 
> Testing
> ---
> 
> grep -r 'with_cxx11' in the mesos repository
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 26071: Sample isolator module.

[Kapil Arya]

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

(Updated Oct. 15, 2014, 12:52 p.m.)


Review request for mesos, Bernd Mathiske, Ian Downes, and Niklas Nielsen.


Changes
---

Makefile.am update for distcheck.


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


Repository: mesos-git


Description
---

Created CPU and Memory isolation modules based on Posix CPU/Memory Isolators.  
These modules are also hooked up to the relevant Isolator tests using the typed 
test mechanism.  It also paves the way for future integration with custom 
modules specified on the command line.


Diffs (updated)
-

  src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
  src/examples/test_isolator_module.cpp PRE-CREATION 
  src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
  src/slave/containerizer/isolator.hpp e52e8b15c740c62ef64b49897d3d6ae5179d4719 
  src/slave/containerizer/isolators/posix.hpp 
f120aafef96343d84f93c5636484509dc972a0a8 
  src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
  src/tests/module.hpp PRE-CREATION 
  src/tests/module.cpp PRE-CREATION 

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


Testing
---

make check with an  Isolator module test.


Thanks,

Kapil Arya

Re: Review Request 26728: Fixed minor typos in configure.ac.

[Dominic Hamon]

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

Ship it!


Ship It!

- Dominic Hamon


On Oct. 14, 2014, 7:07 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26728/
> ---
> 
> (Updated Oct. 14, 2014, 7:07 p.m.)
> 
> 
> Review request for mesos, Cody Maloney and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Fixed minor typos in configure.ac.
> 
> 
> Diffs
> -
> 
>   configure.ac da1c82db31583fc81de658574b9a95628cb84dbc 
> 
> Diff: https://reviews.apache.org/r/26728/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>

Re: Review Request 25184: Delete framework data in TaskStatus to avoid OOM

[Timothy Chen]

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



src/master/master.cpp


Sorry not to keep knit picking, but our style in mesos is to have comments 
end with periods.

We usually don't include the jira ticket number as well. Please just remove 
the line ("MESOS-1746")


- Timothy Chen


On Oct. 15, 2014, 2:23 a.m., Chengwei Yang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25184/
> ---
> 
> (Updated Oct. 15, 2014, 2:23 a.m.)
> 
> 
> Review request for mesos, Adam B and Timothy St. Clair.
> 
> 
> Bugs: MESOS-1746
> https://issues.apache.org/jira/browse/MESOS-1746
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> There was a bug found that Spark use TaskStatus.data to transfer computed
> result and mesos-master RES memory keeps increasing fast and finally will be
> killed by OOM killer.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
> 
> Diff: https://reviews.apache.org/r/25184/diff/
> 
> 
> Testing
> ---
> 
> tested with spark. It's very easy to reproduce this issue (100%) with spark, 
> when spark use mesos as resource manager, its executor driver will put result 
> into TaskStatus. For example, a result of a single task like below.
> 
> 14/08/22 13:29:18 INFO Executor: Serialized size of result for 248 is 17573033
> 
> It's about 16MB large, and a stage of spark generally consist of maybe 
> hundreds of task and finished in tens of seconds, this will put mesos get 
> killed by OOM killer soon.
> 
> 
> Thanks,
> 
> Chengwei Yang
> 
>

Re: Review Request 25184: Delete framework data in TaskStatus to avoid OOM

[Timothy Chen]

> On Oct. 15, 2014, 5:02 p.m., Timothy Chen wrote:
> > src/master/master.cpp, line 4494
> > 
> >
> > Sorry not to keep knit picking, but our style in mesos is to have 
> > comments end with periods.
> > 
> > We usually don't include the jira ticket number as well. Please just 
> > remove the line ("MESOS-1746")

Or Tim if you want to just fix the comment and commit it :) It might be easier


- Timothy


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


On Oct. 15, 2014, 2:23 a.m., Chengwei Yang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25184/
> ---
> 
> (Updated Oct. 15, 2014, 2:23 a.m.)
> 
> 
> Review request for mesos, Adam B and Timothy St. Clair.
> 
> 
> Bugs: MESOS-1746
> https://issues.apache.org/jira/browse/MESOS-1746
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> There was a bug found that Spark use TaskStatus.data to transfer computed
> result and mesos-master RES memory keeps increasing fast and finally will be
> killed by OOM killer.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
> 
> Diff: https://reviews.apache.org/r/25184/diff/
> 
> 
> Testing
> ---
> 
> tested with spark. It's very easy to reproduce this issue (100%) with spark, 
> when spark use mesos as resource manager, its executor driver will put result 
> into TaskStatus. For example, a result of a single task like below.
> 
> 14/08/22 13:29:18 INFO Executor: Serialized size of result for 248 is 17573033
> 
> It's about 16MB large, and a stage of spark generally consist of maybe 
> hundreds of task and finished in tens of seconds, this will put mesos get 
> killed by OOM killer soon.
> 
> 
> Thanks,
> 
> Chengwei Yang
> 
>

Re: Review Request 26071: Sample isolator module.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26071]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 4:52 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26071/
> ---
> 
> (Updated Oct. 15, 2014, 4:52 p.m.)
> 
> 
> Review request for mesos, Bernd Mathiske, Ian Downes, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1384
> https://issues.apache.org/jira/browse/MESOS-1384
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Created CPU and Memory isolation modules based on Posix CPU/Memory Isolators. 
>  These modules are also hooked up to the relevant Isolator tests using the 
> typed test mechanism.  It also paves the way for future integration with 
> custom modules specified on the command line.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/examples/test_isolator_module.cpp PRE-CREATION 
>   src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
>   src/slave/containerizer/isolator.hpp 
> e52e8b15c740c62ef64b49897d3d6ae5179d4719 
>   src/slave/containerizer/isolators/posix.hpp 
> f120aafef96343d84f93c5636484509dc972a0a8 
>   src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
>   src/tests/module.hpp PRE-CREATION 
>   src/tests/module.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/26071/diff/
> 
> 
> Testing
> ---
> 
> make check with an  Isolator module test.
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>

Re: Review Request 26715: Supported O_CLOEXEC for os::open on all platforms.

[Vinod Kone]

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



3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp


s/simply/simplify/



3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp


shouldn't this be a hex value?

also, why are the hex values different for linux and apple?



3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp


s/setting/result/ ?


- Vinod Kone


On Oct. 15, 2014, 12:24 a.m., Jie Yu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26715/
> ---
> 
> (Updated Oct. 15, 2014, 12:24 a.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> This patch allows us to use O_CLOEXEC even if it's not available on some 
> distributions.
> 
> Will follow up with a patch to cleanup the code.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/os.hpp 
> ec41fe412290a152a15a49e091f0bc6436e42cfd 
>   3rdparty/libprocess/3rdparty/stout/tests/os_tests.cpp 
> 898d175980e397493270454aafdf340a96c9cf85 
> 
> Diff: https://reviews.apache.org/r/26715/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> both on mac and linux
> 
> 
> Thanks,
> 
> Jie Yu
> 
>

Re: Review Request 26723: Escape JSON object keys

[Cody Maloney]

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

(Updated Oct. 15, 2014, 6 p.m.)


Review request for mesos and Adam B.


Changes
---

Update per review comments


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


Repository: mesos-git


Description
---

All strings in JSON need to be escaped, including the keys in dictionaries / 
objects.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
719aa964a536cf02dbd2de440157de487ec703b1 

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


Testing
---

make distcheck


Thanks,

Cody Maloney

Re: Review Request 26723: Escape JSON object keys

[Cody Maloney]

> On Oct. 15, 2014, 4:14 a.m., Adam B wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp, line 315
> > 
> >
> > Can this not be const std::string& ?

Good catch


- Cody


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


On Oct. 15, 2014, 6 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26723/
> ---
> 
> (Updated Oct. 15, 2014, 6 p.m.)
> 
> 
> Review request for mesos and Adam B.
> 
> 
> Bugs: MESOS-1878
> https://issues.apache.org/jira/browse/MESOS-1878
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> All strings in JSON need to be escaped, including the keys in dictionaries / 
> objects.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 719aa964a536cf02dbd2de440157de487ec703b1 
> 
> Diff: https://reviews.apache.org/r/26723/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 24341: Added Java replicated log implementation of State.

[Ben Mahler]

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

Ship it!


Looks like you forgot to add the generated header in this patch.


src/Makefile.am


Where is this file?



src/java/src/org/apache/mesos/state/LogState.java


Ah, didn't realize that the State hierarchy in Java was different than in 
C++. I'm just curious, was this for testing purposes, or?


- Ben Mahler


On Oct. 12, 2014, 4:14 a.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24341/
> ---
> 
> (Updated Oct. 12, 2014, 4:14 a.m.)
> 
> 
> Review request for mesos, Ben Mahler and Jie Yu.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/java/jni/org_apache_mesos_state_LogState.cpp PRE-CREATION 
>   src/java/src/org/apache/mesos/state/LogState.java PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/24341/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ankur Chauhan]

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



src/docker/docker.cpp


I did some digging around in the docker source 


https://sourcegraph.com/github.com/docker/docker/.GoPackage/github.com/docker/docker/daemon/.def/Container/Stop/.share

And it seems like we are safe to call stop with any value 
(negative/zero/positive). And the SIGTERM gracefully degrades to a kill it 
fails.

We could simplify the code further by always calling stop and completely 
dropping the kill code path.


- Ankur Chauhan


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26071: Sample isolator module.

[Niklas Nielsen]

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



src/examples/test_isolator_module.cpp


You wired up the modules - you can put in your own info (and serve the 
purpose of tracking down the right author of broken modules ;-)

Here and below



src/examples/test_isolator_module.cpp


'Test' CPU Isolator module?



src/examples/test_isolator_module.cpp


Is this just to exercise the compatible logic? It always returns true. 
Please comment if that is the purpose.



src/slave/containerizer/isolator.hpp


Can we move this to src/modules instead?



src/slave/containerizer/isolators/posix.hpp


Why this change? Here and below.



src/tests/module.hpp


Can you make the name and use of this "module type" more explicit? I had to 
think twice, why this wasn't captured by the regular module 'kind'



src/tests/module.hpp


Can ModuleHelper and TestModule be merged?



src/tests/module.hpp


How about moving the statics into accessors instead? Here and below



src/tests/module.hpp


TestModule is a bit vague term for what it does (and a bit confusing mixed 
with out previous notions of test/example module). I can't come up with a 
better one on the spot, but let's think about it :-)



src/tests/module.cpp


So the idea is that moduleNames gets populated (later on) by flags? For 
example ./mesos-tests --modules="{}" --module_tests="{name: "cpu_isolator", 
"value":  "org_apache_modules_FooBarIsolator"}" ?

Or is it only for internal mapping?

How about using strings to map instead of the enum? You would have to keep 
a second map from the enum to the string eventually?



src/tests/module.cpp


How about using the libraryExtension constant as with the previous module 
patch?


- Niklas Nielsen


On Oct. 15, 2014, 9:52 a.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26071/
> ---
> 
> (Updated Oct. 15, 2014, 9:52 a.m.)
> 
> 
> Review request for mesos, Bernd Mathiske, Ian Downes, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1384
> https://issues.apache.org/jira/browse/MESOS-1384
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Created CPU and Memory isolation modules based on Posix CPU/Memory Isolators. 
>  These modules are also hooked up to the relevant Isolator tests using the 
> typed test mechanism.  It also paves the way for future integration with 
> custom modules specified on the command line.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/examples/test_isolator_module.cpp PRE-CREATION 
>   src/module/manager.cpp 8cc79956a8d3d7cb27016889ec59d138a0b58e45 
>   src/slave/containerizer/isolator.hpp 
> e52e8b15c740c62ef64b49897d3d6ae5179d4719 
>   src/slave/containerizer/isolators/posix.hpp 
> f120aafef96343d84f93c5636484509dc972a0a8 
>   src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
>   src/tests/module.hpp PRE-CREATION 
>   src/tests/module.cpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/26071/diff/
> 
> 
> Testing
> ---
> 
> make check with an  Isolator module test.
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>

Re: Review Request 26698: Added StatusUpdateManager::unacknowledged() API call.

[Niklas Nielsen]

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


Think Adam caught most issues. Only two small nits/questions


src/slave/status_update_manager.cpp


Scan of s/> >/>>/ per new C++11 style



src/slave/status_update_manager.cpp


Can you use stream->next() instead ?


- Niklas Nielsen


On Oct. 14, 2014, 11 a.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26698/
> ---
> 
> (Updated Oct. 14, 2014, 11 a.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added StatusUpdateManager::unacknowledged() API call so that slave can use 
> this info during reregistration.
> 
> 
> Diffs
> -
> 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/slave/status_update_manager.hpp 
> 24e3882ad1969c20a64daf90e408618c310e9a81 
>   src/slave/status_update_manager.cpp 
> 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
>   src/tests/status_update_manager_tests.cpp 
> e9ef1e208cb01535e9366db7872b922c8f06ec40 
> 
> Diff: https://reviews.apache.org/r/26698/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26699: Updated slave re-registration to send unacknowledged task states.

[Niklas Nielsen]

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



src/slave/slave.cpp


What are your guarantees that task_id() is in the states map? Maybe guard 
it?


- Niklas Nielsen


On Oct. 14, 2014, 11:03 a.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26699/
> ---
> 
> (Updated Oct. 14, 2014, 11:03 a.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Slave re-registration now sends both the latest state and unacknowledged 
> state to the master.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/fault_tolerance_tests.cpp 
> a75910d4f486230ba3f1d8927e5f1e5fda6e287b 
>   src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 
> 
> Diff: https://reviews.apache.org/r/26699/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Jenkins build is back to normal : Mesos-Trunk-Ubuntu-Build-In-Src-Set-JAVA_HOME #2171

[Apache Jenkins Server]

See 

Review Request 26767: MESOS-1878: Fix files/files.hpp

[Cody Maloney]

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

Review request for mesos and Timothy Chen.


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


Repository: mesos-git


Description
---

The new path::join logic introduced changed how paths showed up in 
files/files.hpp. Specifically, it made it so that paths more rigorously had / 
didn't have a leading '/' (were absolute).

This caused some inconsistincies when trying to attach, detach, and resolve 
paths, resulting in the files not being found, and therefore not showing up in 
the webui.

The fix is primarily to standardize all the path manipulation routines (See 
review 26766), testing the round trip path thoroughly, then updating files to 
use the helpers to always clean / sanitize the incoming paths so the fit into 
the same pattern.

This should resolve some lurking bugs around detach() as well. Unfortunately I 
couldn't really add more tests there without changing the detach() return, 
which was out of scope for this bugfix.


Diffs
-

  src/files/files.hpp 818087b13cc787d0bd3186bb3e8a069751629bf9 
  src/files/files.cpp 12e8f75aa7bd77d2e81d5d3a7a4d09dd915854aa 
  src/tests/files_tests.cpp a696aa22d56b37ee70c6e64c81a849da6d436451 

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


Testing
---

make distcheck


Thanks,

Cody Maloney

Review Request 26766: MESOS-1878: Add additional helper functions to

[Cody Maloney]

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

Review request for mesos and Timothy Chen.


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


Repository: mesos-git


Description
---

Adds 3 new functions: asAbsolute, clean, and split(). All three were hand-coded 
inside of mesos files (files/files.cpp). This puts them in a common place, and 
adds unit tests for their behavior.

The functions depend on eachother somewhat, so I pulled out the declarations to 
make them all forward declared.


Diffs
-

  3rdparty/libprocess/3rdparty/stout/include/stout/path.hpp 
357a75a8bac497465671456aa9cd9181123cc635 
  3rdparty/libprocess/3rdparty/stout/tests/path_tests.cpp 
aedf93573ea89e46bf7b7b91f2258049af2fd79f 

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


Testing
---

make distcheck


Thanks,

Cody Maloney

Re: Review Request 26723: Escape JSON object keys

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26723]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 6 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26723/
> ---
> 
> (Updated Oct. 15, 2014, 6 p.m.)
> 
> 
> Review request for mesos and Adam B.
> 
> 
> Bugs: MESOS-1878
> https://issues.apache.org/jira/browse/MESOS-1878
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> All strings in JSON need to be escaped, including the keys in dictionaries / 
> objects.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/json.hpp 
> 719aa964a536cf02dbd2de440157de487ec703b1 
> 
> Diff: https://reviews.apache.org/r/26723/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 26728: Fixed minor typos in configure.ac.

[Cody Maloney]

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


LGTM

- Cody Maloney


On Oct. 15, 2014, 2:07 a.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26728/
> ---
> 
> (Updated Oct. 15, 2014, 2:07 a.m.)
> 
> 
> Review request for mesos, Cody Maloney and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Fixed minor typos in configure.ac.
> 
> 
> Diffs
> -
> 
>   configure.ac da1c82db31583fc81de658574b9a95628cb84dbc 
> 
> Diff: https://reviews.apache.org/r/26728/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>

Re: Review Request 24536: Added DIFF to the replicated log state storage implementation.

[Ben Mahler]

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


Looks pretty good, but I think there is an issue with the minimum position 
calculation.

Also curious if `__set` can be cleaned up to avoid all the redundant 
serialization and return paths.


src/Makefile.am


Could you update docs/getting-started.md in this change to reflect what 
users on Ubuntu 12.04 and CentOS 6.5 addtionally need to install, if anything?

Would be great to keep that up-to-date. :)



src/state/log.cpp


This looks a bit redudant, since the caller knows it is calling 'patch', 
this caller would end up double logging:

```
LOG(ERROR) << "Failed to patch ...": patch.error();
```

How about just returning the patch.error()?



src/state/log.cpp


Milliseconds are a good unit for diff time?



src/state/log.cpp


Since you're calling .get() anyway, why not use the Option?

Before:
```
CHECK(snapshots.contains(operation.diff().entry().name()));

Try snapshot =
snapshots.get(operation.diff().entry().name()).get().patch(
entry.position,
operation.diff());
```

After:
```
Option snapshot = snapshots.get(operation.diff().entry().name());

CHECK_SOME(snapshot);

Try patched =
  snapshot.get().patch(entry.position, operation.diff());
```



src/state/log.cpp


This appears to be incorrect:

Say we have 2 Snapshots:
A: (diff=0, position=11)
B: (diff=3, position=10)

Since we skip the diffs here, we'll produce a minimum of position 11, 
something I'm missing?

Don't we need to keep track of the base index for a diff'ed Snapshot to 
determine the correct minimum?



src/state/log.cpp


Can you expand on this a bit? Not sure what this is suggesting, breaking 
out the diff call into an async continuation?



src/state/log.cpp


Curious, if we failed to diff, should we fall back to a snapshot instead?



src/state/log.cpp


Can you collapse these two lines?



src/state/log.cpp


Have you looked at this in a log? It looks like this will always be 0 * 
100.0 given integer division is occurring within the parens.



src/state/log.cpp


Can you collapse this?

```
<< "% the original size (" << Bytes(entry.value().size()) << 
")";
```



src/state/log.cpp


I'm curious whether we can clean up all the redundant serialization and 
return code in this method.

Could the end of this code be the only place that deals with the 
serialization and return?

```
Operation operation;
size_t diffs = 0;

...

string value;
if (!operation.SerializeToString(&value)) {
  return Failure(string("Failed to serialize ") +
  Operation::Type_Name(operation.type()) + " Operation");
}

return writer.append(value)
  .then(defer(self(), &Self::___set, entry, diffs, lambda::_1);
```

Hoping we can avoid 4 locations here where we do the same serialization and 
return.


- Ben Mahler


On Oct. 12, 2014, 5:14 a.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24536/
> ---
> 
> (Updated Oct. 12, 2014, 5:14 a.m.)
> 
> 
> Review request for mesos, Ben Mahler and Jie Yu.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> See summary.
> 
> Note that this hard codes the location of the subversion and Apache Portable 
> Runtime (APR) headers.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/java/jni/org_apache_mesos_state_LogState.cpp PRE-CREATION 
>   src/java/src/org/apache/mesos/state/LogState.java PRE-CREATION 
>   src/messages/state.proto 59276e55fcbebdb754c20d39b13b402fd11c3dad 
>   src/state/log.hpp 6bd054fcd1cf79a2ad1a59da59c9a903cb25882f 
>   src/state/log.cpp fd8b28a0b5d14f5ba3e6fde4695f6d09acf9c56a 
> 
> Diff: https://reviews.apache.org/r/24536/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Re: Review Request 25184: Delete framework data in TaskStatus to avoid OOM

[Timothy St. Clair]

> On Oct. 15, 2014, 5:02 p.m., Timothy Chen wrote:
> > src/master/master.cpp, line 4494
> > 
> >
> > Sorry not to keep knit picking, but our style in mesos is to have 
> > comments end with periods.
> > 
> > We usually don't include the jira ticket number as well. Please just 
> > remove the line ("MESOS-1746")
> 
> Timothy Chen wrote:
> Or Tim if you want to just fix the comment and commit it :) It might be 
> easier

I'll do that.


- Timothy


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


On Oct. 15, 2014, 2:23 a.m., Chengwei Yang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25184/
> ---
> 
> (Updated Oct. 15, 2014, 2:23 a.m.)
> 
> 
> Review request for mesos, Adam B and Timothy St. Clair.
> 
> 
> Bugs: MESOS-1746
> https://issues.apache.org/jira/browse/MESOS-1746
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> There was a bug found that Spark use TaskStatus.data to transfer computed
> result and mesos-master RES memory keeps increasing fast and finally will be
> killed by OOM killer.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
> 
> Diff: https://reviews.apache.org/r/25184/diff/
> 
> 
> Testing
> ---
> 
> tested with spark. It's very easy to reproduce this issue (100%) with spark, 
> when spark use mesos as resource manager, its executor driver will put result 
> into TaskStatus. For example, a result of a single task like below.
> 
> 14/08/22 13:29:18 INFO Executor: Serialized size of result for 248 is 17573033
> 
> It's about 16MB large, and a stage of spark generally consist of maybe 
> hundreds of task and finished in tens of seconds, this will put mesos get 
> killed by OOM killer soon.
> 
> 
> Thanks,
> 
> Chengwei Yang
> 
>

Large changes on the codebase due to MESOS-1872

[Till Toenshoff]

Hey Everyone,

I would like to reach out to the developer community for making sure that we 
find a consensus on https://issues.apache.org/jira/browse/MESOS-1872 
 and other, entire code-base 
affecting changes.

Evelina has bravely proposed three review requests (mesos/libprocess/stout) for 
covering the ticket. There is however some greater risk involved and I wanted 
to be sure that we are all aware of the pro’s and con's of such big cleanups.

+ we may need to do cleanups - even major ones at some point, hence I think we 
need a consensus once and for all regarding tickets of the above nature
- almost all existing RRs will possibly get invalid and everyone with work in 
flight needs to rebase (possibly rather tedious task in particular case).

There may be more.

The only way I can currently see this happening with minimal friction is 
finding a certain date and even time for doing this on a very quick, 
propose/review/commit.

What do you think?

cheers!
Till

 

Re: Review Request 25861: Serialize isolator prepare and cleanup (reversed).

[Ian Downes]

> On Oct. 14, 2014, 1:51 p.m., Timothy Chen wrote:
> > src/slave/containerizer/mesos/containerizer.cpp, line 1022
> > 
> >
> > Not sure if I'm missing something, but if you chain all lambdas with 
> > .then, only the last one will be the failed one right?

The chaining is on the outer Future> which accumulates the 
individual Futures when they are [ready|failed|discarded], not the futures 
themselves. I want cleanup to be called on each isolator, regardless of the 
success of preceeding isolators. The list can contain any ordering of futures 
in any !pending state.


- Ian


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


On Oct. 14, 2014, 1:34 p.m., Ian Downes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25861/
> ---
> 
> (Updated Oct. 14, 2014, 1:34 p.m.)
> 
> 
> Review request for mesos, Jie Yu and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Change from doing in parallel and collect()ing to serial according to the 
> vector of isolators (reversed order for cleanup).
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/mesos/containerizer.hpp 
> bf246ca649ca4a461cebf1aee6908a2d58eec362 
>   src/slave/containerizer/mesos/containerizer.cpp 
> 9d083294caa5c5a47ba3ceaa1b57346144cb795c 
> 
> Diff: https://reviews.apache.org/r/25861/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Re: Review Request 25549: Basic filesystem isolator for Linux.

[Ian Downes]

> On Oct. 14, 2014, 1:43 p.m., Timothy Chen wrote:
> > src/slave/containerizer/linux_launcher.cpp, line 355
> > 
> >
> > print the contianer id for easier tracing in the logs.

Added to caller's log message.


- Ian


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


On Oct. 14, 2014, 1:31 p.m., Ian Downes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25549/
> ---
> 
> (Updated Oct. 14, 2014, 1:31 p.m.)
> 
> 
> Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone.
> 
> 
> Bugs: MESOS-1586
> https://issues.apache.org/jira/browse/MESOS-1586
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Does not report usage or enforce quota but can create 'private' directories 
> for each container which mask parts of the shared host filesystem.
> 
> This review replaces https://reviews.apache.org/r/24178/ because of some file 
> renaming. I addressed all comments from earlier reviews.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 6b93e9000761857c4f335f2a8c8088e155078f54 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/common/parse.hpp c9ca30fde5580d8e388f3c616e78df2b032ac0ad 
>   src/common/type_utils.hpp f10b2d31f2781bd056898f93eb8e8b6d9809e80b 
>   src/slave/containerizer/isolators/filesystem/shared.hpp PRE-CREATION 
>   src/slave/containerizer/isolators/filesystem/shared.cpp PRE-CREATION 
>   src/slave/containerizer/linux_launcher.cpp 
> f7bc894830a7ca3f55465dacc7b653cdc2d7758b 
>   src/slave/containerizer/mesos/containerizer.cpp 
> 9d083294caa5c5a47ba3ceaa1b57346144cb795c 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
> 
> Diff: https://reviews.apache.org/r/25549/diff/
> 
> 
> Testing
> ---
> 
> make check # added a test
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Re: Review Request 25549: Basic filesystem isolator for Linux.

[Ian Downes]

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

(Updated Oct. 15, 2014, 12:25 p.m.)


Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone.


Changes
---

Improved log message.


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


Repository: mesos-git


Description
---

Does not report usage or enforce quota but can create 'private' directories for 
each container which mask parts of the shared host filesystem.

This review replaces https://reviews.apache.org/r/24178/ because of some file 
renaming. I addressed all comments from earlier reviews.


Diffs (updated)
-

  include/mesos/mesos.proto 6b93e9000761857c4f335f2a8c8088e155078f54 
  src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
  src/common/parse.hpp c9ca30fde5580d8e388f3c616e78df2b032ac0ad 
  src/common/type_utils.hpp f10b2d31f2781bd056898f93eb8e8b6d9809e80b 
  src/slave/containerizer/isolators/filesystem/shared.hpp PRE-CREATION 
  src/slave/containerizer/isolators/filesystem/shared.cpp PRE-CREATION 
  src/slave/containerizer/linux_launcher.cpp 
f7bc894830a7ca3f55465dacc7b653cdc2d7758b 
  src/slave/containerizer/mesos/containerizer.cpp 
9d083294caa5c5a47ba3ceaa1b57346144cb795c 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
  src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
  src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
  src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 

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


Testing
---

make check # added a test


Thanks,

Ian Downes

Re: Review Request 25966: Use pid namespace in LinuxLauncher::destroy().

[Ian Downes]

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

(Updated Oct. 15, 2014, 12:27 p.m.)


Review request for mesos, Jie Yu and Vinod Kone.


Changes
---

Added review dependencies


Repository: mesos-git


Description
---

Check if a container is running in a pid namespace and thus all processes can 
be killed by the kernel, rather than using the freezer.


Diffs
-

  src/slave/containerizer/linux_launcher.cpp 
f7bc894830a7ca3f55465dacc7b653cdc2d7758b 
  src/slave/containerizer/mesos/containerizer.cpp 
9d083294caa5c5a47ba3ceaa1b57346144cb795c 
  src/tests/slave_recovery_tests.cpp 4fb357bd55f69f71193e92fd03765b808f932d33 

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


Testing
---


Thanks,

Ian Downes

Re: Review Request 25525: MESOS-1739: Allow slave reconfiguration on restart

[Cody Maloney]

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

(Updated Oct. 15, 2014, 7:30 p.m.)


Review request for mesos, Adam B and Vinod Kone.


Changes
---

Fixed build error


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


Repository: mesos-git


Description
---

Allows attributes and resources to be set to a superset of what they were 
previously on a slave restart.

Incorporates all comments from: 
https://issues.apache.org/jira/browse/MESOS-1739
and the former review request:
https://reviews.apache.org/r/25111/


Diffs (updated)
-

  src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
  src/common/attributes.hpp 0a043d5b5dca804c6dd215cabd2704f24df71a33 
  src/common/attributes.cpp aab114e1a5932e3f218b850e1afc7f2ef0f10e21 
  src/common/slaveinfo_utils.hpp PRE-CREATION 
  src/common/slaveinfo_utils.cpp PRE-CREATION 
  src/master/allocator.hpp 02d20d0cc802805bc702891306aa42894531b223 
  src/master/hierarchical_allocator_process.hpp 
31dfb2cc86e2e74da43f05fbada10976ce65f3e4 
  src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
  src/master/master.cpp 0a5c9a374062a241c90ea238725fbb8dd2408ef4 
  src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
  src/tests/attributes_tests.cpp 240a8cac18ac12178cf73e8eeb88bd50e3fcc03b 
  src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
  src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 

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


Testing
---

make check on localhost


Thanks,

Cody Maloney

Re: Large changes on the codebase due to MESOS-1872

[Benjamin Hindman]

My $0.02: Let's make the cleanups as we go. If you work in a function that
can get cleaned up, clean it up. Maybe clean up the entire file if you're
making changes to multiple functions. Doing this iteratively not only keeps
folks from having to do tedious rebases but it also preserves, for the most
part, the git blame history which can be invaluable when working in a file
and trying to ask for some help.

On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff  wrote:

> Hey Everyone,
>
> I would like to reach out to the developer community for making sure that
> we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872 <
> https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> code-base affecting changes.
>
> Evelina has bravely proposed three review requests
> (mesos/libprocess/stout) for covering the ticket. There is however some
> greater risk involved and I wanted to be sure that we are all aware of the
> pro’s and con's of such big cleanups.
>
> + we may need to do cleanups - even major ones at some point, hence I
> think we need a consensus once and for all regarding tickets of the above
> nature
> - almost all existing RRs will possibly get invalid and everyone with work
> in flight needs to rebase (possibly rather tedious task in particular case).
>
> There may be more.
>
> The only way I can currently see this happening with minimal friction is
> finding a certain date and even time for doing this on a very quick,
> propose/review/commit.
>
> What do you think?
>
> cheers!
> Till
>
>

Re: Large changes on the codebase due to MESOS-1872

[Dominic Hamon]

+1

until we get to the point where the out-of-compliance files are minimal,
doing them as we go should be sufficient. It moves the code-base forward to
compliance without being disruptive.

it does make RRs more complex as there are changes that are not geared
towards the main aim of the patch, but this is still less burden on the
community as a whole.

On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman 
wrote:

> My $0.02: Let's make the cleanups as we go. If you work in a function that
> can get cleaned up, clean it up. Maybe clean up the entire file if you're
> making changes to multiple functions. Doing this iteratively not only keeps
> folks from having to do tedious rebases but it also preserves, for the most
> part, the git blame history which can be invaluable when working in a file
> and trying to ask for some help.
>
> On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff  wrote:
>
> > Hey Everyone,
> >
> > I would like to reach out to the developer community for making sure that
> > we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
> <
> > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > code-base affecting changes.
> >
> > Evelina has bravely proposed three review requests
> > (mesos/libprocess/stout) for covering the ticket. There is however some
> > greater risk involved and I wanted to be sure that we are all aware of
> the
> > pro’s and con's of such big cleanups.
> >
> > + we may need to do cleanups - even major ones at some point, hence I
> > think we need a consensus once and for all regarding tickets of the above
> > nature
> > - almost all existing RRs will possibly get invalid and everyone with
> work
> > in flight needs to rebase (possibly rather tedious task in particular
> case).
> >
> > There may be more.
> >
> > The only way I can currently see this happening with minimal friction is
> > finding a certain date and even time for doing this on a very quick,
> > propose/review/commit.
> >
> > What do you think?
> >
> > cheers!
> > Till
> >
> >
>



-- 
Dominic Hamon | @mrdo | Twitter
*There are no bad ideas; only good ideas that go horribly wrong.*

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ryan Thomas]

> On Oct. 15, 2014, 4:25 p.m., Timothy Chen wrote:
> > src/docker/docker.cpp, line 479
> > 
> >
> > Also, have you tried with the docker cli what's the exit status when 
> > you run docker stop if either 1) docker succesffully stopped 2) docker 
> > killed it in the end 3) can't do both

>From reading through the docker code, it appears to be the same as if it 
>failed to kill the container. If it fails to SIGTERM the container (that is it 
>fails to send the signal) it will attempt a SIGKILL on it, the errors returned 
>are the same as the kill path.


- Ryan


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


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ryan Thomas]

> On Oct. 15, 2014, 4:25 p.m., Timothy Chen wrote:
> > src/docker/docker.cpp, line 480
> > 
> >
> > Does docker stop -t 0 doesn't do this for you?

It will take a slightly different path in docker, but it will end up with the 
same result. I will update to remove.


- Ryan


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


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Large changes on the codebase due to MESOS-1872

[Tim St Clair]

It would be nice is we had a place where it is ok to make such changes, and a 
place for stable incremental changes.  

-stable 
-unstable 

In absence of that, I agree with the consensus.

Cheers,
Tim 


- Original Message -
> From: "Till Toenshoff" 
> To: "mesos" 
> Sent: Wednesday, October 15, 2014 2:13:12 PM
> Subject: Large changes on the codebase due to MESOS-1872
> 
> Hey Everyone,
> 
> I would like to reach out to the developer community for making sure that we
> find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
>  and other, entire
> code-base affecting changes.
> 
> Evelina has bravely proposed three review requests (mesos/libprocess/stout)
> for covering the ticket. There is however some greater risk involved and I
> wanted to be sure that we are all aware of the pro’s and con's of such big
> cleanups.
> 
> + we may need to do cleanups - even major ones at some point, hence I think
> we need a consensus once and for all regarding tickets of the above nature
> - almost all existing RRs will possibly get invalid and everyone with work in
> flight needs to rebase (possibly rather tedious task in particular case).
> 
> There may be more.
> 
> The only way I can currently see this happening with minimal friction is
> finding a certain date and even time for doing this on a very quick,
> propose/review/commit.
> 
> What do you think?
> 
> cheers!
> Till
> 
> 

-- 
Cheers,
Timothy St. Clair
Red Hat Inc.

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ryan Thomas]

> On Oct. 15, 2014, 6:01 p.m., Ankur Chauhan wrote:
> > src/docker/docker.cpp, line 479
> > 
> >
> > I did some digging around in the docker source 
> > 
> > 
> > https://sourcegraph.com/github.com/docker/docker/.GoPackage/github.com/docker/docker/daemon/.def/Container/Stop/.share
> > 
> > And it seems like we are safe to call stop with any value 
> > (negative/zero/positive). And the SIGTERM gracefully degrades to a kill it 
> > fails.
> > 
> > We could simplify the code further by always calling stop and 
> > completely dropping the kill code path.

It looks like the WaitStop function in docker will wait forever if it is 
supplied with a negative value, so I think we should keep the negative check in.

Otherwise I agree with simplifying it, a 0 timeout will essentially drop 
straight into a kill.


- Ryan


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


On Oct. 15, 2014, 10:58 a.m., Ryan Thomas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26736/
> ---
> 
> (Updated Oct. 15, 2014, 10:58 a.m.)
> 
> 
> Review request for mesos.
> 
> 
> Bugs: MESOS-1925
> https://issues.apache.org/jira/browse/MESOS-1925
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
> docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
> will be run, otherwise a docker stop with the timeout in seconds is used. A 
> negative value will result in a Failure.
> 
> 
> Diffs
> -
> 
>   src/docker/docker.hpp 9656f15547a522f9866c28c78d431508771c795a 
>   src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
>   src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/tests/docker_containerizer_tests.cpp 
> 67d60a885d65edbcbbf702bce83a54d1a5c0411f 
>   src/tests/docker_tests.cpp 04139af2c377226554d53e9dbce93868da1dc1ba 
> 
> Diff: https://reviews.apache.org/r/26736/diff/
> 
> 
> Testing
> ---
> 
> make check
> sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Ryan Thomas
> 
>

Re: Large changes on the codebase due to MESOS-1872

[Benjamin Mahler]

> - almost all existing RRs will possibly get invalid

Why is that Till? Are you thinking of merge conflicts?

>If you work in a function that can get cleaned up, clean it up.
>Maybe clean up the entire file if you're making changes to multiple
functions.

But please separate the patches. :)

> git blame history which can be invaluable when working in a file and
trying to ask for some help.

Till, does 'git blame -w' ignore this particular change, since she's only
removing whitespace?

On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman 
wrote:

> My $0.02: Let's make the cleanups as we go. If you work in a function that
> can get cleaned up, clean it up. Maybe clean up the entire file if you're
> making changes to multiple functions. Doing this iteratively not only keeps
> folks from having to do tedious rebases but it also preserves, for the most
> part, the git blame history which can be invaluable when working in a file
> and trying to ask for some help.
>
> On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff  wrote:
>
> > Hey Everyone,
> >
> > I would like to reach out to the developer community for making sure that
> > we find a consensus on https://issues.apache.org/jira/browse/MESOS-1872
> <
> > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > code-base affecting changes.
> >
> > Evelina has bravely proposed three review requests
> > (mesos/libprocess/stout) for covering the ticket. There is however some
> > greater risk involved and I wanted to be sure that we are all aware of
> the
> > pro’s and con's of such big cleanups.
> >
> > + we may need to do cleanups - even major ones at some point, hence I
> > think we need a consensus once and for all regarding tickets of the above
> > nature
> > - almost all existing RRs will possibly get invalid and everyone with
> work
> > in flight needs to rebase (possibly rather tedious task in particular
> case).
> >
> > There may be more.
> >
> > The only way I can currently see this happening with minimal friction is
> > finding a certain date and even time for doing this on a very quick,
> > propose/review/commit.
> >
> > What do you think?
> >
> > cheers!
> > Till
> >
> >
>

Re: Large changes on the codebase due to MESOS-1872

[Cody Maloney]

I think in this case there isn't a lot of value added relative to the cost.
It is an invasive change that doesn't change how easy the code is to work
with, and will periodically break things like '\' aligned to the right for
continuing macros.

For some things like migrating the mesos codebase style to one which can be
as mechanically enforced as possible or resolving. I also potentially see
some things like directory moving happening in the future (making it so
there isn't a 3rdparty embedded in a 3rdparty).

Practically if we are making sweeping changes which will effect everything
dramatically, it is a lot cleaner to have one commit which makes the
switch, even though it acts as a synchronization point for development,
because then it is one commit which gets encountered in a 'git blame' (And
you can then do another blame starting at that one commit).

On Wed, Oct 15, 2014 at 12:49 PM, Dominic Hamon 
wrote:

> +1
>
> until we get to the point where the out-of-compliance files are minimal,
> doing them as we go should be sufficient. It moves the code-base forward to
> compliance without being disruptive.
>
> it does make RRs more complex as there are changes that are not geared
> towards the main aim of the patch, but this is still less burden on the
> community as a whole.
>
> On Wed, Oct 15, 2014 at 12:35 PM, Benjamin Hindman  >
> wrote:
>
> > My $0.02: Let's make the cleanups as we go. If you work in a function
> that
> > can get cleaned up, clean it up. Maybe clean up the entire file if you're
> > making changes to multiple functions. Doing this iteratively not only
> keeps
> > folks from having to do tedious rebases but it also preserves, for the
> most
> > part, the git blame history which can be invaluable when working in a
> file
> > and trying to ask for some help.
> >
> > On Wed, Oct 15, 2014 at 12:13 PM, Till Toenshoff 
> wrote:
> >
> > > Hey Everyone,
> > >
> > > I would like to reach out to the developer community for making sure
> that
> > > we find a consensus on
> https://issues.apache.org/jira/browse/MESOS-1872
> > <
> > > https://issues.apache.org/jira/browse/MESOS-1872> and other, entire
> > > code-base affecting changes.
> > >
> > > Evelina has bravely proposed three review requests
> > > (mesos/libprocess/stout) for covering the ticket. There is however some
> > > greater risk involved and I wanted to be sure that we are all aware of
> > the
> > > pro’s and con's of such big cleanups.
> > >
> > > + we may need to do cleanups - even major ones at some point, hence I
> > > think we need a consensus once and for all regarding tickets of the
> above
> > > nature
> > > - almost all existing RRs will possibly get invalid and everyone with
> > work
> > > in flight needs to rebase (possibly rather tedious task in particular
> > case).
> > >
> > > There may be more.
> > >
> > > The only way I can currently see this happening with minimal friction
> is
> > > finding a certain date and even time for doing this on a very quick,
> > > propose/review/commit.
> > >
> > > What do you think?
> > >
> > > cheers!
> > > Till
> > >
> > >
> >
>
>
>
> --
> Dominic Hamon | @mrdo | Twitter
> *There are no bad ideas; only good ideas that go horribly wrong.*
>

Re: Review Request 26767: MESOS-1878: Fix files/files.hpp

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26766, 26767]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 6:46 p.m., Cody Maloney wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26767/
> ---
> 
> (Updated Oct. 15, 2014, 6:46 p.m.)
> 
> 
> Review request for mesos and Timothy Chen.
> 
> 
> Bugs: MESOS-1878
> https://issues.apache.org/jira/browse/MESOS-1878
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> The new path::join logic introduced changed how paths showed up in 
> files/files.hpp. Specifically, it made it so that paths more rigorously had / 
> didn't have a leading '/' (were absolute).
> 
> This caused some inconsistincies when trying to attach, detach, and resolve 
> paths, resulting in the files not being found, and therefore not showing up 
> in the webui.
> 
> The fix is primarily to standardize all the path manipulation routines (See 
> review 26766), testing the round trip path thoroughly, then updating files to 
> use the helpers to always clean / sanitize the incoming paths so the fit into 
> the same pattern.
> 
> This should resolve some lurking bugs around detach() as well. Unfortunately 
> I couldn't really add more tests there without changing the detach() return, 
> which was out of scope for this bugfix.
> 
> 
> Diffs
> -
> 
>   src/files/files.hpp 818087b13cc787d0bd3186bb3e8a069751629bf9 
>   src/files/files.cpp 12e8f75aa7bd77d2e81d5d3a7a4d09dd915854aa 
>   src/tests/files_tests.cpp a696aa22d56b37ee70c6e64c81a849da6d436451 
> 
> Diff: https://reviews.apache.org/r/26767/diff/
> 
> 
> Testing
> ---
> 
> make distcheck
> 
> 
> Thanks,
> 
> Cody Maloney
> 
>

Re: Review Request 26736: Ensure docker calls stop if a docker_stop_timeout is provided Added the flag docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill will be run, otherw

[Ryan Thomas]

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

(Updated Oct. 15, 2014, 8:30 p.m.)


Review request for mesos.


Changes
---

Added patch with review changes.


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


Repository: mesos-git


Description
---

Ensure docker calls stop if a docker_stop_timeout is provided Added the flag 
docker_stop_timeout that defaults to 0, if the timeout is 0 the a docker kill 
will be run, otherwise a docker stop with the timeout in seconds is used. A 
negative value will result in a Failure.


Diffs (updated)
-

  src/docker/docker.cpp e09b51c4f5101c3a8e77caf12b208c88f47fbcb2 
  src/slave/containerizer/docker.cpp 9a2948951f57f3ab16291df51cd9f33e5e96add4 
  src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 

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


Testing
---

make check
sudo bin/mesos-tests.sh --gtest_filter="DOCKER" --verbose 
support/mesos-style.py


Thanks,

Ryan Thomas

Re: Review Request 26509: Added --module flag for Mesos slave.

[Niklas Nielsen]

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

Ship it!


Ship It!

- Niklas Nielsen


On Oct. 12, 2014, 1:08 p.m., Kapil Arya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26509/
> ---
> 
> (Updated Oct. 12, 2014, 1:08 p.m.)
> 
> 
> Review request for mesos, Niklas Nielsen and Till Toenshoff.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added --module flag for Mesos slave.
> 
> 
> Diffs
> -
> 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/slave/main.cpp 1eafb356b58613d4ab8bd6dd245583e0d6f25a97 
> 
> Diff: https://reviews.apache.org/r/26509/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kapil Arya
> 
>

Re: [2/2] git commit: Minor style fix from https://reviews.apache.org/r/25184/

[Benjamin Mahler]

Are you using the git commit hook in support/?

Sent from my iPhone

> On Oct 15, 2014, at 12:14 PM, tstcl...@apache.org wrote:
> 
> Minor style fix from https://reviews.apache.org/r/25184/
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/6e104170
> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/6e104170
> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/6e104170
> 
> Branch: refs/heads/master
> Commit: 6e1041704b1de3936302233d9327ff69e6dcbda5
> Parents: 8538eed
> Author: Timothy St. Clair 
> Authored: Wed Oct 15 14:13:46 2014 -0500
> Committer: Timothy St. Clair 
> Committed: Wed Oct 15 14:13:46 2014 -0500
> 
> --
> src/master/master.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/mesos/blob/6e104170/src/master/master.cpp
> --
> diff --git a/src/master/master.cpp b/src/master/master.cpp
> index efb90d6..0a5c9a3 100644
> --- a/src/master/master.cpp
> +++ b/src/master/master.cpp
> @@ -4491,7 +4491,7 @@ void Master::updateTask(Task* task, const TaskStatus& 
> status)
>   // For example: mesos-master is running on a machine with 4GB free memory,
>   // if every task stores 10MB data into TaskStatus, then mesos-master will be
>   // killed by OOM killer after have 400 tasks finished.
> -  // MESOS-1746
> +  // MESOS-1746.
>   task->mutable_statuses(task->statuses_size() - 1)->clear_data();
> 
>   task->set_state(status.state());
> 

Re: Review Request 26150: Libprocess Benchmark

[Joris Van Remoortere]

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

(Updated Oct. 15, 2014, 8:42 p.m.)


Review request for mesos and Niklas Nielsen.


Changes
---

Fix pipe bug.
Fix null terminated buffer bug.


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


Repository: mesos-git


Description
---

A benchmark for libprocess.
It forks num_proc times and launched num_threads "libprocess" processes in each 
child. They are aware of the "master"'s (parent) address and all play ping pong 
with it.
This benchmark measures throughput in terms of the number of RPCs handled per 
second using persistent (linked) connections.

A new test file (benchmarks) is introduced because we want to fork before 
libprocess is initialized. This allows us to prevent short-circuiting of 
message passing between processes under the same ProcessManager. This way we 
force the execution path of the underlying event management system.


Diffs (updated)
-

  3rdparty/libprocess/Makefile.am 616618e 
  3rdparty/libprocess/src/tests/benchmarks.cpp PRE-CREATION 

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


Testing
---

make check in 3rdparty/libprocess
support/mesos-style.py


Thanks,

Joris Van Remoortere

Re: Review Request 26476: Remove dynamic allocation from Option.

[Niklas Nielsen]

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


High-level: LGTM
Have a couple of nits and we should be good to go.


3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp


As it's is a boolean expression, we wrap differently: 
http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Boolean_Expressions



3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp


t != NULL or isSome()



3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp


s/!t/t == NULL/



3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp


s/t/t != NULL/



3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp


reduce 2 spaces left


- Niklas Nielsen


On Oct. 8, 2014, 6:35 p.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26476/
> ---
> 
> (Updated Oct. 8, 2014, 6:35 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Remove dynamic allocations from Option class.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 47fe92c 
> 
> Diff: https://reviews.apache.org/r/26476/diff/
> 
> 
> Testing
> ---
> 
> make check
> support/mesos-style.py
> valgrind (reduced allocation count)
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Re: Review Request 26578: Memory cleanup: libprocess gc finalize

[Niklas Nielsen]

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



3rdparty/libprocess/include/process/gc.hpp


How about the include for unique ptr?



3rdparty/libprocess/include/process/gc.hpp


Let 'iter' spell out what it is for (and expand to a full word).


- Niklas Nielsen


On Oct. 13, 2014, 10:29 a.m., Joris Van Remoortere wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26578/
> ---
> 
> (Updated Oct. 13, 2014, 10:29 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Implement the finalize() virtual override for Libprocess' garbage collector.
> This terminates all processes registered with the garbage collector when the 
> garbage collector terminates.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/gc.hpp e83c636 
> 
> Diff: https://reviews.apache.org/r/26578/diff/
> 
> 
> Testing
> ---
> 
> make check
> support/mesos-style.py
> 
> 
> Thanks,
> 
> Joris Van Remoortere
> 
>

Large changes on the codebase due to MESOS-1872

[Evelina Dumitrescu]

Hi,


When I picked this issue, I didn't thought that the code changes will raise 
this kind of problems. :))
Therefore, I share the same opinion:  we should be aware of this for the 
further commits and adapt the coding style step by step to the C++11 standard.
Also, I think that Github doesn't use the -w option for git blame and this 
could cause difficulties when browsing the code.


Evelina

Re: Review Request 25549: Basic filesystem isolator for Linux.

[Mesos ReviewBot]

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


Patch looks great!

Reviews applied: [26273, 25861, 24177, 25655, 25549]

All tests passed.

- Mesos ReviewBot


On Oct. 15, 2014, 7:25 p.m., Ian Downes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25549/
> ---
> 
> (Updated Oct. 15, 2014, 7:25 p.m.)
> 
> 
> Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone.
> 
> 
> Bugs: MESOS-1586
> https://issues.apache.org/jira/browse/MESOS-1586
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Does not report usage or enforce quota but can create 'private' directories 
> for each container which mask parts of the shared host filesystem.
> 
> This review replaces https://reviews.apache.org/r/24178/ because of some file 
> renaming. I addressed all comments from earlier reviews.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 6b93e9000761857c4f335f2a8c8088e155078f54 
>   src/Makefile.am d503c8df73cda15a9d59254e8265e4a5d0e003a4 
>   src/common/parse.hpp c9ca30fde5580d8e388f3c616e78df2b032ac0ad 
>   src/common/type_utils.hpp f10b2d31f2781bd056898f93eb8e8b6d9809e80b 
>   src/slave/containerizer/isolators/filesystem/shared.hpp PRE-CREATION 
>   src/slave/containerizer/isolators/filesystem/shared.cpp PRE-CREATION 
>   src/slave/containerizer/linux_launcher.cpp 
> f7bc894830a7ca3f55465dacc7b653cdc2d7758b 
>   src/slave/containerizer/mesos/containerizer.cpp 
> 9d083294caa5c5a47ba3ceaa1b57346144cb795c 
>   src/slave/flags.hpp 16f0cc2ab5ba16a39499608174278b3082e0585d 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/isolator_tests.cpp c38f87632cb6984543cb3767dbd656cde7459610 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
> 
> Diff: https://reviews.apache.org/r/25549/diff/
> 
> 
> Testing
> ---
> 
> make check # added a test
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Review Request 26775: Added module loading support for local clusters.

[Till Toenshoff]

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

Review request for mesos, Kapil Arya and Niklas Nielsen.


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


Repository: mesos-git


Description
---

Frameworks triggering a local cluster (--master=local) now have module loading 
support via slave and master flags (--modules). Duplicate modules (slave vs. 
master) are filtered before loading.


Diffs
-

  src/local/local.cpp 66de798 

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


Testing
---

make check & functional check using upcoming module related patches.


Thanks,

Till Toenshoff

Re: Review Request 26697: Added StartSlave() overload that takes status update manager.

[Vinod Kone]

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

(Updated Oct. 15, 2014, 9:26 p.m.)


Review request for mesos and Ben Mahler.


Changes
---

rebased. NNFR.


Repository: mesos-git


Description
---

Added this overload to be able to use for testing status update manager. Used 
in the subsequent review.


Diffs (updated)
-

  src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
  src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 

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


Testing
---

make check


Thanks,

Vinod Kone

Re: Review Request 26698: Added StatusUpdateManager::unacknowledged() API call.

[Vinod Kone]

> On Oct. 14, 2014, 10:51 p.m., Adam B wrote:
> > src/messages/messages.proto, line 45
> > 
> >
> > Maybe 'unacknowledged_status' would be more accurate, since the uuid is 
> > associated with the StatusUpdate message itself, and this could be one of 
> > many status updates with the TASK_RUNNING state, of which some may have 
> > already been acknowledged and others are waiting behind this one. In that 
> > case, the TASK_RUNNING state has already been received and acknowledged, 
> > but it's the other pending status updates that are unacknowledged. Maybe 
> > 'pending_state' or 'pending_status' would be better.

The hard part in naming here is because the Task.State.state will still be in 
the state after an ACK has been received by the master/slave. It only changes 
when the next update is received by the status update manager. Let me sleep on 
it.


> On Oct. 14, 2014, 10:51 p.m., Adam B wrote:
> > src/messages/messages.proto, line 58
> > 
> >
> > This uuid corresponds to the uuid of a StatusUpdateMessage not the 
> > state itself. Why wouldn't you want to include the entire StatusUpdate or 
> > TaskStatus message instead of picking only the fields you think you need 
> > now? I'm sure the arbitrary size of the 'data' field comes into play, but 
> > I'd just like to know if you considered it and why you rejected it.
> > 
> > Is uuid really always going to be required? Maybe it should be called 
> > 'status_uuid'?

Yes. Preferrably I would have liked to just use StatusUpdate here instead of 
coming up with a new inner message. But after looking at recent reports about 
'data' OOMing the master, I went for the conservative approach. Maybe we can 
just use StatusUpdate but scrub the un-necessary fields? Not sure which one is 
better and less confusing.

As you must have seen in one of the subsequent reviews, master needs the uuid 
to correctly deal with status update acks.


> On Oct. 14, 2014, 10:51 p.m., Adam B wrote:
> > src/tests/status_update_manager_tests.cpp, line 807
> > 
> >
> > Times(1) is implicit, unneeded.
> > "If neither WillOnce() nor WillRepeatedly() is in the EXPECT_CALL(), 
> > the inferred cardinality is Times(1)."
> > - 
> > https://code.google.com/p/googlemock/wiki/ForDummies#Cardinalities:_How_Many_Times_Will_It_Be_Called?
> >  (No offense)

Yep. Overlooked it here and in other reviews, as i copy pasted stuff from other 
tests :) will fix.


> On Oct. 14, 2014, 10:51 p.m., Adam B wrote:
> > src/tests/status_update_manager_tests.cpp, line 806
> > 
> >
> > Maybe you'd like to fill in some of these '_' blanks to at least 
> > guarantee the messages are coming from and going to the right pids?

We typically don't explicitly set "_" unless we are interested in them. Makes 
for less cruft in the test.


- Vinod


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


On Oct. 14, 2014, 6 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26698/
> ---
> 
> (Updated Oct. 14, 2014, 6 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added StatusUpdateManager::unacknowledged() API call so that slave can use 
> this info during reregistration.
> 
> 
> Diffs
> -
> 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/slave/status_update_manager.hpp 
> 24e3882ad1969c20a64daf90e408618c310e9a81 
>   src/slave/status_update_manager.cpp 
> 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
>   src/tests/status_update_manager_tests.cpp 
> e9ef1e208cb01535e9366db7872b922c8f06ec40 
> 
> Diff: https://reviews.apache.org/r/26698/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26697: Added StartSlave() overload that takes status update manager.

[Ben Mahler]

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

Ship it!


Ship It!

- Ben Mahler


On Oct. 15, 2014, 9:26 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26697/
> ---
> 
> (Updated Oct. 15, 2014, 9:26 p.m.)
> 
> 
> Review request for mesos and Ben Mahler.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added this overload to be able to use for testing status update manager. Used 
> in the subsequent review.
> 
> 
> Diffs
> -
> 
>   src/tests/mesos.hpp 957e2233cc11c438fd80d3b6d1907a1223093104 
>   src/tests/mesos.cpp 3dcb2acd5ad4ab5e3a7b4fe524ee077558112773 
> 
> Diff: https://reviews.apache.org/r/26697/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26698: Added StatusUpdateManager::unacknowledged() API call.

[Vinod Kone]

> On Oct. 15, 2014, 6:17 p.m., Niklas Nielsen wrote:
> > src/slave/status_update_manager.cpp, lines 292-293
> > 
> >
> > Can you use stream->next() instead ?

done.


- Vinod


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


On Oct. 14, 2014, 6 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26698/
> ---
> 
> (Updated Oct. 14, 2014, 6 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Added StatusUpdateManager::unacknowledged() API call so that slave can use 
> this info during reregistration.
> 
> 
> Diffs
> -
> 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/slave/status_update_manager.hpp 
> 24e3882ad1969c20a64daf90e408618c310e9a81 
>   src/slave/status_update_manager.cpp 
> 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
>   src/tests/status_update_manager_tests.cpp 
> e9ef1e208cb01535e9366db7872b922c8f06ec40 
> 
> Diff: https://reviews.apache.org/r/26698/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26698: Added StatusUpdateManager::unacknowledged() API call.

[Vinod Kone]

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

(Updated Oct. 15, 2014, 9:27 p.m.)


Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.


Changes
---

Addressed comments.


Repository: mesos-git


Description
---

Added StatusUpdateManager::unacknowledged() API call so that slave can use this 
info during reregistration.


Diffs (updated)
-

  src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
  src/slave/status_update_manager.hpp 24e3882ad1969c20a64daf90e408618c310e9a81 
  src/slave/status_update_manager.cpp 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
  src/tests/status_update_manager_tests.cpp 
e9ef1e208cb01535e9366db7872b922c8f06ec40 

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


Testing
---

make check

Ran new test 1000 times.


Thanks,

Vinod Kone

Re: Review Request 25966: Use pid namespace in LinuxLauncher::destroy().

[Mesos ReviewBot]

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


Bad patch!

Reviews applied: [25864, 25864]

Failed command: git apply --index 25864.patch

Error:
 error: patch failed: src/linux/cgroups.hpp:362
error: src/linux/cgroups.hpp: patch does not apply
error: patch failed: src/linux/cgroups.cpp:1702
error: src/linux/cgroups.cpp: patch does not apply

- Mesos ReviewBot


On Oct. 15, 2014, 7:27 p.m., Ian Downes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25966/
> ---
> 
> (Updated Oct. 15, 2014, 7:27 p.m.)
> 
> 
> Review request for mesos, Jie Yu and Vinod Kone.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Check if a container is running in a pid namespace and thus all processes can 
> be killed by the kernel, rather than using the freezer.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/linux_launcher.cpp 
> f7bc894830a7ca3f55465dacc7b653cdc2d7758b 
>   src/slave/containerizer/mesos/containerizer.cpp 
> 9d083294caa5c5a47ba3ceaa1b57346144cb795c 
>   src/tests/slave_recovery_tests.cpp 4fb357bd55f69f71193e92fd03765b808f932d33 
> 
> Diff: https://reviews.apache.org/r/25966/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Re: Review Request 26699: Updated slave re-registration to send unacknowledged task states.

[Vinod Kone]

> On Oct. 15, 2014, 6:26 p.m., Niklas Nielsen wrote:
> > src/slave/slave.cpp, line 1014
> > 
> >
> > What are your guarantees that task_id() is in the states map? Maybe 
> > guard it?

it is inside a "if states contains task id" condition. am i missing something?


- Vinod


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


On Oct. 14, 2014, 6:03 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26699/
> ---
> 
> (Updated Oct. 14, 2014, 6:03 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Slave re-registration now sends both the latest state and unacknowledged 
> state to the master.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/fault_tolerance_tests.cpp 
> a75910d4f486230ba3f1d8927e5f1e5fda6e287b 
>   src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 
> 
> Diff: https://reviews.apache.org/r/26699/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26699: Updated slave re-registration to send unacknowledged task states.

[Vinod Kone]

> On Oct. 15, 2014, 4:03 a.m., Adam B wrote:
> > src/slave/slave.cpp, lines 938-948
> > 
> >
> > Couldn't the Slave and the SUM get out of sync here? Right now, the SUM 
> > will flush its pending status updates as soon as a new master is detected.
> > I'm imagining a scenario where the SUM is flushing status updates and 
> > the slave handles a status ACK interleaved with a slave re-registration 
> > delivering stale or out-of-sync task states.
> > Wouldn't it just be better if the SUM didn't flush until after the 
> > slave has successfully re-registered?

Definitely thought about this race. 

Yes, it would be better if SUM did the flush after re-registration but I think 
it is still a race because re-registration could happen due to ZK blips where 
updates and acks are in flight.

I added a comment on why it is safe. Let me know if you still have concerns.


> On Oct. 15, 2014, 4:03 a.m., Adam B wrote:
> > src/tests/slave_tests.cpp, lines 1088-1089
> > 
> >
> > Verify that it's actually a TASK_RUNNING?

I typically only test for things that the test is verifying, to avoid bloating 
the test.


- Vinod


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


On Oct. 14, 2014, 6:03 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26699/
> ---
> 
> (Updated Oct. 14, 2014, 6:03 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Slave re-registration now sends both the latest state and unacknowledged 
> state to the master.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
>   src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
>   src/tests/fault_tolerance_tests.cpp 
> a75910d4f486230ba3f1d8927e5f1e5fda6e287b 
>   src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 
> 
> Diff: https://reviews.apache.org/r/26699/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26699: Updated slave re-registration to send unacknowledged task states.

[Vinod Kone]

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

(Updated Oct. 15, 2014, 9:29 p.m.)


Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.


Changes
---

Addressed comments.


Bugs: MESOS-1799 and MESOS-1817
https://issues.apache.org/jira/browse/MESOS-1799
https://issues.apache.org/jira/browse/MESOS-1817


Repository: mesos-git


Description
---

Slave re-registration now sends both the latest state and unacknowledged state 
to the master.


Diffs (updated)
-

  src/slave/slave.hpp 342b09fc084c20d98d096bb129830440179c092c 
  src/slave/slave.cpp 0e342ed35e3db3b68f9f32b6cf4ace23e4a4db38 
  src/tests/fault_tolerance_tests.cpp a75910d4f486230ba3f1d8927e5f1e5fda6e287b 
  src/tests/slave_tests.cpp f585bdd20ae1af466f2c1b4d85331ac67451552f 

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


Testing
---

make check

Ran new test 1000 times.


Thanks,

Vinod Kone

Re: Review Request 26476: Remove dynamic allocation from Option.

[Joris Van Remoortere]

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

(Updated Oct. 15, 2014, 9:29 p.m.)


Review request for mesos, Benjamin Hindman and Niklas Nielsen.


Changes
---

fix style issues.


Repository: mesos-git


Description
---

Remove dynamic allocations from Option class.


Diffs (updated)
-

  3rdparty/libprocess/3rdparty/stout/include/stout/option.hpp 47fe92c 

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


Testing
---

make check
support/mesos-style.py
valgrind (reduced allocation count)


Thanks,

Joris Van Remoortere

Re: Review Request 26700: Updated StatusUpdateManager to send latest task state in update.

[Vinod Kone]

> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > I like the direction this is going. Our internal bandaid fix set the 
> > latest/terminal_state in stream->next instead of forward(), but I don't 
> > think it makes much of a difference. A few questions:
> > - Where does the uuid come into play?
> > - Why track latest_state for anything but the terminal state?

* uuid comes into play in the next review
* we use latest_state for consistency with what the slave reports. makes the 
state updating logic in master simpler (see next review).


> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > src/messages/messages.proto, lines 80-83
> > 
> >
> > Kinda confusing that (at some point in time) StatusUpdate.status.state 
> > == Task.unacknowledged_state.state and Task.state == 
> > StatusUpdate.latest_state.state (did I get that right?)
> > I guess it would be too hard to rename the existing protobufs and make 
> > schedulers/executors recompile.

You got that right. And yes, changing the old names would be 
upgradability/compatibility nightmare. Suggestions for better names for the new 
fields I added are welcome.


> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > src/messages/messages.proto, line 83
> > 
> >
> > Why does the StatusUpdate.latest_state need the other update's uuid? 
> > Why can't it just be a plain TaskState? I don't see uuid being used here.

You are right! This could just be TaskState. Fixed. Thanks.


> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > src/slave/status_update_manager.cpp, lines 415-416
> > 
> >
> > Is there any reason to send this if it's not a terminal state? 
> > Otherwise, you're just diffing between RUNNING and RUNNING.

see above. done this mainly for consistency.


> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > src/tests/status_update_manager_tests.cpp, line 902
> > 
> >
> > Verify state is TASK_RUNNING?

see my comments in previous review.


> On Oct. 15, 2014, 4:52 a.m., Adam B wrote:
> > src/tests/status_update_manager_tests.cpp, line 935
> > 
> >
> > Verify the uuid value too?

N/A since we no longer include uuid.


- Vinod


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


On Oct. 14, 2014, 6:04 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26700/
> ---
> 
> (Updated Oct. 14, 2014, 6:04 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Status update manager now sends both latest and unacknowledged states to the 
> master.
> 
> 
> Diffs
> -
> 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/slave/status_update_manager.cpp 
> 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
>   src/tests/status_update_manager_tests.cpp 
> e9ef1e208cb01535e9366db7872b922c8f06ec40 
> 
> Diff: https://reviews.apache.org/r/26700/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26700: Updated StatusUpdateManager to send latest task state in update.

[Vinod Kone]

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

(Updated Oct. 15, 2014, 9:30 p.m.)


Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.


Changes
---

Addressed comments.


Bugs: MESOS-1799 and MESOS-1817
https://issues.apache.org/jira/browse/MESOS-1799
https://issues.apache.org/jira/browse/MESOS-1817


Repository: mesos-git


Description
---

Status update manager now sends both latest and unacknowledged states to the 
master.


Diffs (updated)
-

  src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
  src/slave/status_update_manager.cpp 5d5cf234ef2dd47fa4b1f67be761dbca31659451 
  src/tests/status_update_manager_tests.cpp 
e9ef1e208cb01535e9366db7872b922c8f06ec40 

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


Testing
---

make check

Ran new test 1000 times.


Thanks,

Vinod Kone

Re: Review Request 26701: Updated master to update task unacknowledged state properly.

[Vinod Kone]

> On Oct. 15, 2014, 7:23 a.m., Adam B wrote:
> > src/master/master.cpp, line 2826
> > 
> >
> > When would the uuids ever be different? If the scheduler re-acked a 
> > previous terminal update when the master expected to be on a second 
> > terminal update/ack?

it could be different because status update manager retries updates. for 
example, SUM sent 2 TASK_RUNNING updates (one of them a retry). before the ACK 
for the 2nd TASK_RUNNING reaches master, if it received a TASK_FINISHED update, 
we would accidentally remove the task on the reception of the 2nd TASK_RUNNING 
ACK.


- Vinod


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


On Oct. 14, 2014, 6:06 p.m., Vinod Kone wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26701/
> ---
> 
> (Updated Oct. 14, 2014, 6:06 p.m.)
> 
> 
> Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.
> 
> 
> Bugs: MESOS-1799 and MESOS-1817
> https://issues.apache.org/jira/browse/MESOS-1799
> https://issues.apache.org/jira/browse/MESOS-1817
> 
> 
> Repository: mesos-git
> 
> 
> Description
> ---
> 
> Master now maintains the latest and unacknowledged states of the task.
> 
> 
> Diffs
> -
> 
>   src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
>   src/master/master.cpp cb46cec0674b3aa031450c5b4f48f4f8bb92767d 
>   src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
>   src/tests/master_tests.cpp d9dc40c6f5aaa66e1f7a0e1b7e4d9cdc586ca0fd 
> 
> Diff: https://reviews.apache.org/r/26701/diff/
> 
> 
> Testing
> ---
> 
> make check
> 
> Ran the new test 1000 times.
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Re: Review Request 26701: Updated master to update task unacknowledged state properly.

[Vinod Kone]

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

(Updated Oct. 15, 2014, 9:32 p.m.)


Review request for mesos, Adam B, Ben Mahler, and Niklas Nielsen.


Changes
---

Addressed comments.


Bugs: MESOS-1799 and MESOS-1817
https://issues.apache.org/jira/browse/MESOS-1799
https://issues.apache.org/jira/browse/MESOS-1817


Repository: mesos-git


Description
---

Master now maintains the latest and unacknowledged states of the task.


Diffs (updated)
-

  src/master/master.hpp 14f1d0fd240c9cd0718d0238e1fbb9c733190205 
  src/master/master.cpp 1b1ce0de3065ced45890777d42c69ef1091f5699 
  src/messages/messages.proto 8de7f9699f43aa2780f4a39fed087abcf5e5af99 
  src/tests/master_tests.cpp d9dc40c6f5aaa66e1f7a0e1b7e4d9cdc586ca0fd 

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


Testing
---

make check

Ran the new test 1000 times.


Thanks,

Vinod Kone