Re: Review Request 66343: Added test for difference operator of hashset.

[Benjamin Mahler]

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


Ship it!




looks like all of these ASSERTs can be EXPECTs?

- Benjamin Mahler


On March 28, 2018, 6:23 p.m., Zhitao Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66343/
> ---
> 
> (Updated March 28, 2018, 6:23 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Chun-Hung Hsiao, and Jason Lai.
> 
> 
> Bugs: MESOS-8746
> https://issues.apache.org/jira/browse/MESOS-8746
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added test for difference operator of hashset.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/tests/hashset_tests.cpp 
> d2b7bf248647c63c00c8c82b8176130c87c50eb4 
> 
> 
> Diff: https://reviews.apache.org/r/66343/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Re: Review Request 66342: Added difference operator overload for hashset.

[Benjamin Mahler]

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


Ship it!




Ship It!

- Benjamin Mahler


On March 28, 2018, 6:23 p.m., Zhitao Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66342/
> ---
> 
> (Updated March 28, 2018, 6:23 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Chun-Hung Hsiao, and Jason Lai.
> 
> 
> Bugs: MESOS-8746
> https://issues.apache.org/jira/browse/MESOS-8746
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added difference operator overload for hashset.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/hashset.hpp 
> 6af209c53185207b53396e7687e3bd7357e57bf1 
> 
> 
> Diff: https://reviews.apache.org/r/66342/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Re: Review Request 66445: Windows: Cleaned up included CRT headers.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 7:26 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66445/
> ---
> 
> (Updated April 4, 2018, 7:26 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8759
> https://issues.apache.org/jira/browse/MESOS-8759
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The set `errno` value in `os::kill()` is never checked (especially on
> Windows), so `_set_errno()` and thus `errno.h` were removed.
> 
> The `fcntl.h` is used only to provide `O_CREAT` etc., and so belonged
> in `open.hpp`, not `windows.hpp`.
> 
> The remaining headers, `direct.h`, `io.h`, `process.h`, and `stdlib.h`
> were no longer used or needed as the respective CRT APIs were
> replaced.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/kill.hpp 
> 9cec1117fac3cf6bd624fc7db524ef1ad10cd55d 
>   3rdparty/stout/include/stout/os/windows/mkdtemp.hpp 
> 9181429383a991fe2b87701d2bfd0e858ac2537b 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/rmdir.hpp 
> a2926dab2c8e219cf5938c4df27f83488198dd6b 
>   3rdparty/stout/include/stout/os/windows/sendfile.hpp 
> fff5872db6b3f69464e41e6d108a107e4eeabd12 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
>   3rdparty/stout/include/stout/windows/dynamiclibrary.hpp 
> 5b3cbf4f36ea9ac0411df52b4cfea8ef75fecbb5 
>   3rdparty/stout/include/stout/windows/os.hpp 
> 739ee4da3f09d2a9597d4451e755e77903e9287d 
> 
> 
> Diff: https://reviews.apache.org/r/66445/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66444: Windows: Made `signals.hpp` compile.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:58 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66444/
> ---
> 
> (Updated April 4, 2018, 5:58 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This file had never been included before, so it didn't compile. It
> needed to include `unimplemented.hpp`, and because `Suppressor` isn't
> implemented, the initializers had to be deleted.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/signals.hpp 
> 0ed24771625e58c1de8b1aa96b70f5aae1638bd4 
> 
> 
> Diff: https://reviews.apache.org/r/66444/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66443: Fixed `Subprocess::ChildHook::CHDIR()` to use `os::chdir()`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:58 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66443/
> ---
> 
> (Updated April 4, 2018, 5:58 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This needed to use the Stout API so that the correct Windows
> implementation is used, as `::chdir` is part of the CRT.
> 
> Also included used but not included `stout/os/*` headers.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/subprocess.cpp 
> 898326360d6b4f0a50d6ef3f7c86141d0aa70438 
> 
> 
> Diff: https://reviews.apache.org/r/66443/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66442: Windows: Fixed `os::abort()` to use `WriteFile()`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 5, 2018, 2:06 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66442/
> ---
> 
> (Updated April 5, 2018, 2:06 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Windows: Fixed `os::abort()` to use `WriteFile()`.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/abort.hpp 
> 4fd233dfcd4359791dd176820f3a6040947bb291 
> 
> 
> Diff: https://reviews.apache.org/r/66442/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66440: Replaced `open()` with `os::open()` in `http_proxy.cpp`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/libprocess/src/http_proxy.cpp
Line 155 (original), 155 (patched)


We might need to `#ifdef` here to handle the `GetLastError` on Windows and 
`errno` on Linux.


- Akash Gupta


On April 4, 2018, 5:57 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66440/
> ---
> 
> (Updated April 4, 2018, 5:57 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8675
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Replaced `open()` with `os::open()` in `http_proxy.cpp`.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/http_proxy.cpp 
> 25d63791e4788a488f96303aabeed0fa77ad7992 
> 
> 
> Diff: https://reviews.apache.org/r/66440/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66439: Windows: Made `protobuf::write()` use CRT file descriptor explicitly.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:56 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66439/
> ---
> 
> (Updated April 4, 2018, 5:56 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8675
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This is another edge case where a third-party library (protobuf)
> requires a CRT integer file descriptor. Thus we duplicate the `int_fd`
> and then explicitly allocate via `crt()`, which requires that we also
> manually close it via `_close()`.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/protobuf.hpp 
> 2fa5072e3c62c487da0dccffdd38d2fa1a615dc0 
> 
> 
> Diff: https://reviews.apache.org/r/66439/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66438: Windows: Made `libevent` use CRT file descriptor explicitly.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 7:19 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66438/
> ---
> 
> (Updated April 4, 2018, 7:19 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8675
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This is an edge case where a third-party library (libevent) requires a
> CRT integer file descriptor. Thus we duplicate the `int_fd` and then
> explicitly allocate via `crt()`, which requires that we also manually
> close it via `_close()`.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/libevent_ssl_socket.cpp 
> 4de161dbf9198e9c74b1e80838b8a5d52006a562 
> 
> 
> Diff: https://reviews.apache.org/r/66438/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66433: Windows: Made `net::download()` use CRT file descriptor explicitly.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 7:18 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66433/
> ---
> 
> (Updated April 4, 2018, 7:18 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8675
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This is an edge case where a third-party library (libcurl) requires a
> CRT integer file descriptor. Thus we explicitly allocate one via
> `crt()`, which requires that we also manually close it via `_close()`,
> not `os::close()`.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
> 
> 
> Diff: https://reviews.apache.org/r/66433/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66437: Windows: Removed `FD_CRT` from `WindowsFD` abstraction.

[Akash Gupta]

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




3rdparty/stout/include/stout/os/windows/fd.hpp
Line 57 (original), 58 (patched)


I'm not sure if every default constructed WindowsFD will be an invalid 
WindowsFD handle. Do you know what happens to the enum and union? I thought C++ 
doesn't specify anything, so it can have any value if uninitialized. I don't 
know how these default constructed WindowsFD are used, but you might want to 
set it to an invalid handle explcitly.



3rdparty/stout/include/stout/os/windows/fd.hpp
Line 82 (original), 72 (patched)


small nit, but you can use the handle constructor here:

`WindowsFD(int crt) : WindowsFD(INVALID_HANDLE_VALUE) { ... }`



3rdparty/stout/include/stout/os/windows/fd.hpp
Line 85 (original), 84 (patched)


Same thing here with using the socket constructor.


- Akash Gupta


On April 5, 2018, 1:58 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66437/
> ---
> 
> (Updated April 5, 2018, 1:58 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675 and MESOS-8683
> https://issues.apache.org/jira/browse/MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8683
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> After all the CRT APIs were replaced with Windows APIs, we no longer
> needed to support the semantics of an `int` file descriptor in
> general (in the sense of opening a CRT handle that's associated with
> the actual kernel object for the given `HANDLE`). There are specific
> use cases (usually third-party code) which still require a CRT
> int-like file descriptor, which the `crt()` function explicitly
> allocates (this allocation used to be done in the constructor).
> 
> Thus the entire `FD_CRT` type was removed from the `WindowsFD`
> abstraction. It still acts like an `int` in the sense that it can be
> constructed from one and compared to one. However, construction via
> `int` only supports the standard file descriptors 0, 1, and 2 for
> `stdin`, `stdout`, and `stderr`. Any other construction creates an
> `int_fd` which holds an `INVALID_HANDLE` value. When being compared to
> an `int`, the abstraction simply returns -1 if it is invalid (based on
> the result of the `is_valid()` method) or 0 if it is valid. This is to
> support the semantics of checking validity by something like `if (fd <
> 0)` or `if (fd == -1)`.
> 
> With the deletion of the `FD_CRT` type from `WindowsFD`, all the Stout
> APIs that switched on the type were simplified, with the last of the
> CRT code deleted.
> 
> Thanks to the introduction of the private `int get_valid()` function,
> and the removal of the `FD_CRT` type, the comparison operators became
> much simpler.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/close.hpp 
> ff635e44235d63888a210cd68d49f6678a851e31 
>   3rdparty/stout/include/stout/os/windows/dup.hpp 
> 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/fd.hpp 
> d7f8cdf1ad877eb55589bf5a9e75d295f91990a7 
>   3rdparty/stout/include/stout/os/windows/read.hpp 
> 8047ad590fcc46d3ec46b551472d8c518ae49cc1 
>   3rdparty/stout/include/stout/os/windows/write.hpp 
> 71006489918d9495d37d2fdfdca08b40b419481a 
>   3rdparty/stout/tests/os/filesystem_tests.cpp 
> c190baa2230298e428d4034b90dccffb59b4e710 
> 
> 
> Diff: https://reviews.apache.org/r/66437/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66347: Added a test for killing executor during task launch.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66118', '66119', '66120', '65679', '66126', '66143', 
'66322', '66144', '66346', '66145', '66178', '66323', '66347']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66347

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66347/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (115 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1062 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (32 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (37 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (70 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (837 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (863 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (850 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (880 ms total)

[--] Global test environment tear-down
[==] 954 tests from 94 test cases ran. (457967 ms total)
[  PASSED  ] 953 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66347/logs/mesos-tests-stderr.log):

```
I0406 01:52:38.213266 17376 master.cpp:10449] Updating the state of task 
8202d585-8501-4f0f-af99-99d5221664e6 of framework 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0406 01:52:38.213266 16828 slave.cpI0406 01:52:38.017261 16720 exec.cpp:162] 
Version: 1.6.0
I0406 01:52:38.046293 17060 exec.cpp:236] Executor registered on agent 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013-S0
I0406 01:52:38.050273 14888 executor.cpp:177] Received SUBSCRIBED event
I0406 01:52:38.056270 14888 executor.cpp:181] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0406 01:52:38.056270 14888 executor.cpp:177] Received LAUNCH event
I0406 01:52:38.061272 14888 executor.cpp:649] Starting task 
8202d585-8501-4f0f-af99-99d5221664e6
I0406 01:52:38.152279 14888 executor.cpp:484] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0406 01:52:38.182284 14888 executor.cpp:662] Forked command at 9260
I0406 01:52:38.215266  6556 exec.cpp:445] Executor asked to shutdown
I0406 01:52:38.216271 13664 executor.cpp:177] Received SHUTDOWN event
I0406 01:52:38.216271 13664 executor.cpp:759] Shutting down
I0406 01:52:38.216271 13664 executor.cpp:869] Sending SIGTERM to process tree 
at pid 9p:3973] Shutting down framework 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013-
I0406 01:52:38.213266 16828 slave.cpp:6670] Shutting down executor 
'8202d585-8501-4f0f-af99-99d5221664e6' of framework 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013- at executor(1)@10.3.1.8:56062
I0406 01:52:38.215266 16828 slave.cpp:923] Agent terminating
W0406 01:52:38.215266 16828 slave.cpp:3969] Ignoring shutdown framework 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013- because it is terminating
I0406 01:52:38.215266 17376 master.cpp:10548] Removing task 
8202d585-8501-4f0f-af99-99d5221664e6 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework 1ddd4bb7-0d3a-4b39-b079-7df7737e8013- on 
agent 1ddd4bb7-0d3a-4b39-b079-7df7737e8013-S0 at slave(423)@10.3.1.8:56040 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0406 01:52:38.219265 14112 containerizer.cpp:2338] Destroying container 
87759137-6927-42c9-8034-edf3b40308a4 in RUNNING state
I0406 01:52:38.219265 17376 master.cpp:1295] Agent 
1ddd4bb7-0d3a-4b39-b079-7df7737e8013-S0 at slave(423)@10.3.1.8:56040 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0406 01:52:38.219265 14112 containerizer.cpp:2952] Transitioning the state of 
container 87759137-6927-42c9-8034-edf3b40308a4 from RUNNING to DESTROYING
I0406 01:52:38.219265 17376 master.cpp:3286] Disconnecting agent 

Re: Review Request 66347: Added a test for killing executor during task launch.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66118, 66119, 66120, 65679, 66126, 66143, 66322, 66144, 
66346, 66145, 66178, 66323, 66347]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 6, 2018, 6:07 a.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66347/
> ---
> 
> (Updated April 6, 2018, 6:07 a.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This test verifies that when agent shuts down a running
> executor, launching tasks on the agent that use the same
> executor will be dropped properly.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66347/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Re: Review Request 66481: Converted `pid` in command executor to `Option`.

[Mesos Reviewbot Windows]

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



PASS: Mesos patch 66481 was successfully built and tested.

Reviews applied: `['66481']`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66481

- Mesos Reviewbot Windows


On April 5, 2018, 11:31 p.m., Zhitao Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66481/
> ---
> 
> (Updated April 5, 2018, 11:31 p.m.)
> 
> 
> Review request for mesos, Andrew Schwartzmeyer and James Peach.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This avoids unix's assumption that `pid_t` is a signed integer (which is
> not the case on Windows) and explicitly shows whether a pid has been
> assigned from launching.
> 
> We also changed the member variable to `pid_` to avoid variable
> shadowing in `reaped` method.
> 
> 
> Diffs
> -
> 
>   src/launcher/executor.cpp 383655230fcdad30b652ea984cb9f5fc9c49dd38 
> 
> 
> Diff: https://reviews.apache.org/r/66481/diff/1/
> 
> 
> Testing
> ---
> 
> `make` on Linux.
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Re: Review Request 66347: Added a test for killing executor during task launch.

[Meng Zhu]

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

(Updated April 5, 2018, 5:37 p.m.)


Review request for mesos and Greg Mann.


Changes
---

set expectations in the right order.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

This test verifies that when agent shuts down a running
executor, launching tasks on the agent that use the same
executor will be dropped properly.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66347/diff/6/

Changes: https://reviews.apache.org/r/66347/diff/5-6/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 66323: Added tests for failed task launch on agent.

[Meng Zhu]

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

(Updated April 5, 2018, 5:36 p.m.)


Review request for mesos and Greg Mann.


Changes
---

set expectations in the right order.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

These tests verify the agent behavior of launching
several task groups using the same executor. When
task groups are launching on the agent (before creating
any executor), if the first received task group
fails to launch, later task groups will get dropped.
If a later received task group fails to launch, the first
received task group should still launch successfully.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66323/diff/8/

Changes: https://reviews.apache.org/r/66323/diff/7-8/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 66178: Added a test to verify that task launch order is enforced.

[Meng Zhu]

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

(Updated April 5, 2018, 5:35 p.m.)


Review request for mesos, Chun-Hung Hsiao and Greg Mann.


Changes
---

set expectations in the right order.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

Agent should launch the task in their receiving order.
On the task launch path, there are currently two
asynchronous steps which may complete out of order:
unschedule GC and task authorization.

This test simulates the reordering of the completions
of task authorization step and verify that, despite the
reordering, tasks can still launch in their original order.


Diffs (updated)
-

  src/tests/mesos.hpp 46c271b5c5bedbdabd58b3cdbb82216d55c846bd 
  src/tests/mesos.cpp d82963195573dd9ed7d12a7708f64a236b28cdf1 
  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66178/diff/7/

Changes: https://reviews.apache.org/r/66178/diff/6-7/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 65939: Updated role endpoints for hierarchical accounting.

[Kapil Arya]

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



Hey Till,

I have added some comments. Most are minor style sthings which you should feel 
free to ignore :-).

I have two high-level comments (we already talked about the first one but 
thought of putting it in here anyways):
1. Backwards compatibility wrt to the Role proto for /roles endpoint and the 
likes. 
2. I noticed that we have `master->roles.getRole()`, etc., scattered all over 
the code and wondering if we should put some of these methods in the Master 
class itself for better readability?


include/mesos/mesos.proto
Line 3407 (original), 3407-3409 (patched)


I wonder how this would affect backwards compatibility. Do we need to keep 
`resources` as is and add `allocated` and `total_allocated` in addition? If we 
do this, we'd probably need to figure out a way to handle old vs new frameworks.



include/mesos/v1/master/master.proto
Lines 458-459 (original), 458-459 (patched)


Please update the corresponding V0 master.proto as well.



src/master/master.hpp
Lines 139-140 (patched)


Now that we are keeping track of `allocatedResources` and 
`totalAllocatedResources`, we can replace this hashmap with a simple hashset. 
We don't seem to be using `Framework*` elsewhere.



src/master/master.hpp
Lines 173-174 (patched)


Can we change the third sentence ("An implicit ... active role.") to 
something like:
An implicit role is not active - frameworks are connected to its child 
roles instead.



src/master/master.hpp
Lines 178 (patched)


I am not sure if I understand what `returned in ["a", "a/b"]` means.



src/master/master.hpp
Lines 181 (patched)


Would this search the framework in child roles as well? Can we expand to 
comment to explicitly mention it? Something like:

` Checks if the given framework is being tracked under the given role or 
its child roles`



src/master/master.cpp
Lines 495-501 (patched)


Just a minor comment. Would it improve readability if we were to switch the 
if condition with the CHECK condition? As in:
```
if (!roleMap.contains(path)) {
  CHECK(!parent->children.contains(path));
  VLOG(1) ...
  ...
}
```



src/master/master.cpp
Lines 519 (patched)


s/stop going up the tree/not removing it

Here and below. That way it applies to the top-level roles as well.



src/master/master.cpp
Lines 520 (patched)


s/break/return/ ?

Here and below.



src/master/master.cpp
Lines 529 (patched)


What if we bring this line after VLOG line. Further, we need a 
`CHECK_NOTNULL(parent);` here?



src/master/master.cpp
Lines 531 (patched)


s/childless/leaf ?



src/master/master.cpp
Lines 572 (patched)


Wondering if we should use `getRole(role)->frameworks.contains(id)` for 
uniformity.



src/master/master.cpp
Lines 587 (patched)


Do we need a CHECK here, or is that too defensive?



src/master/master.cpp
Lines 619 (patched)


This VLOG seems to stand out. Do we need similar log messages in other 
functions (`addResources`, etc.)?


- Kapil Arya


On April 5, 2018, 12:15 p.m., Till Toenshoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65939/
> ---
> 
> (Updated April 5, 2018, 12:15 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, Kapil Arya, 
> Michael Park, and Meng Zhu.
> 
> 
> Bugs: MESOS-8069
> https://issues.apache.org/jira/browse/MESOS-8069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> When listing role "a", resources allocated to role "a/b" are added to
> those allocated to role "a". These changes affect both, the "/roles"
> endpoint as well as the V1 HTTP Call "GET_ROLES".
> Adds dynamic hierarchical role tracking to the master.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 676f0b090cad7ebf59eb32556f17ff8b5f247907 
>   include/mesos/v1/master/master.proto 
> ddb28f96b2a3a439bb9a829995a9a3015f65ba43 
>   

Re: Review Request 65940: Added test validating hierarchical role accounting.

[Kapil Arya]

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


Ship it!




This looks good to me. I am wondering if we need more test coverage for 
insertion/deletion of roles implicit roles. Perhaps a TODO?


src/tests/api_tests.cpp
Lines 1072 (patched)


For completeness, can we check `roles(0)` as well?


- Kapil Arya


On April 5, 2018, 12:15 p.m., Till Toenshoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65940/
> ---
> 
> (Updated April 5, 2018, 12:15 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, Kapil Arya, and 
> Michael Park.
> 
> 
> Bugs: MESOS-8069
> https://issues.apache.org/jira/browse/MESOS-8069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added test validating hierarchical role accounting.
> 
> 
> Diffs
> -
> 
>   src/tests/api_tests.cpp dd8e221d8fd1b2a241505345337897e4ee4a6347 
>   src/tests/role_tests.cpp a609ed27ef828ca82efc0d269669cda92e5f50a1 
> 
> 
> Diff: https://reviews.apache.org/r/65940/diff/2/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Re: Review Request 66435: Added overloads for `int_fd` to `os::stat::isdir()` and `size()`.

[Andrew Schwartzmeyer]

> On April 5, 2018, 4:58 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/posix/stat.hpp
> > Lines 66 (patched)
> > 
> >
> > Did you mean `const int_fd& fd`?

Not on POSIX, it's just an `int`.


> On April 5, 2018, 4:58 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/posix/stat.hpp
> > Lines 99-101 (patched)
> > 
> >
> > Ditto on `const int_fd& fd`

Ditto.


> On April 5, 2018, 4:58 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/posix/stat.hpp
> > Lines 133 (patched)
> > 
> >
> > Ditto on `const int_fd& fd`

Ditto.


- Andrew


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


On April 3, 2018, 10:52 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66435/
> ---
> 
> (Updated April 3, 2018, 10:52 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> These should be refactored to share the common code, and the
> additional overloads added to the other APIs too. However, it is not
> currently necessary, and would go unused.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/posix/stat.hpp 
> 58353742b39bac4fbfcb2ab7708f0f8719ea5b3b 
>   3rdparty/stout/include/stout/os/windows/stat.hpp 
> c04953ee42f45dd80b6362fbeeddf4a0a20e7412 
> 
> 
> Diff: https://reviews.apache.org/r/66435/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66481: Converted `pid` in command executor to `Option`.

[James Peach]

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



I think we should just change all the usages of `pid` rather than renaming it 
to `pid_`.

- James Peach


On April 5, 2018, 11:31 p.m., Zhitao Li wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66481/
> ---
> 
> (Updated April 5, 2018, 11:31 p.m.)
> 
> 
> Review request for mesos, Andrew Schwartzmeyer and James Peach.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This avoids unix's assumption that `pid_t` is a signed integer (which is
> not the case on Windows) and explicitly shows whether a pid has been
> assigned from launching.
> 
> We also changed the member variable to `pid_` to avoid variable
> shadowing in `reaped` method.
> 
> 
> Diffs
> -
> 
>   src/launcher/executor.cpp 383655230fcdad30b652ea984cb9f5fc9c49dd38 
> 
> 
> Diff: https://reviews.apache.org/r/66481/diff/1/
> 
> 
> Testing
> ---
> 
> `make` on Linux.
> 
> 
> Thanks,
> 
> Zhitao Li
> 
>

Re: Review Request 66436: Removed use of `fstat()` from `http.cpp` and `http_proxy.cpp`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:54 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66436/
> ---
> 
> (Updated April 4, 2018, 5:54 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The functions `os::stat::size()` and `os::stat::isdir()` are now
> overloaded for an `int_fd` type, using `fstat()` on POSIX, and the
> equivalent functions with a `HANDLE` on Windows. This allowed us to
> remove the use of `::fstat()`, which was not abstracted, and not
> supported on Windows without the use of a CRT integer file descriptor.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/http.cpp 63dd2c1f629ac316d0b31f8a854e482ae6eda634 
>   3rdparty/libprocess/src/http_proxy.cpp 
> 25d63791e4788a488f96303aabeed0fa77ad7992 
> 
> 
> Diff: https://reviews.apache.org/r/66436/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66435: Added overloads for `int_fd` to `os::stat::isdir()` and `size()`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/posix/stat.hpp
Lines 66 (patched)


Did you mean `const int_fd& fd`?



3rdparty/stout/include/stout/os/posix/stat.hpp
Lines 99-101 (patched)


Ditto on `const int_fd& fd`



3rdparty/stout/include/stout/os/posix/stat.hpp
Lines 133 (patched)


Ditto on `const int_fd& fd`


- Akash Gupta


On April 4, 2018, 5:52 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66435/
> ---
> 
> (Updated April 4, 2018, 5:52 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> These should be refactored to share the common code, and the
> additional overloads added to the other APIs too. However, it is not
> currently necessary, and would go unused.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/posix/stat.hpp 
> 58353742b39bac4fbfcb2ab7708f0f8719ea5b3b 
>   3rdparty/stout/include/stout/os/windows/stat.hpp 
> c04953ee42f45dd80b6362fbeeddf4a0a20e7412 
> 
> 
> Diff: https://reviews.apache.org/r/66435/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66434: Windows: Refactored `subprocess_windows.cpp` to use `os::open()`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 7:18 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66434/
> ---
> 
> (Updated April 4, 2018, 7:18 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Previously, `os::open()` used the CRT function `_wopen()`, and so this
> file was written to use the `CreateFile()` API directly. Now that
> `os::open()` uses the Windows API, all this duplicate code can be
> deleted in favor of using the `os::open()` and
> `internal::windows::set_inherit()`. The major benefit here is that the
> logic now almost exactly matches the POSIX counterpart in
> `subprocess_posix.cpp`, to the point that we may want to recombine
> these files in the future.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/subprocess_windows.cpp 
> 1a91fbe7aeb44174ccfa2e7e299bc7dd52a11b8a 
> 
> 
> Diff: https://reviews.apache.org/r/66434/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66432: Windows: Fixed `os::write()` to use `WriteFile()`.

[Akash Gupta]

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




3rdparty/stout/include/stout/os/windows/write.hpp
Lines 35 (patched)


Same comment as previous read.hpp:

Do you know why the return value is `ssize_t` instead of a `Try`. 
Is it due to it being async signal safe?

I imagine the callers of this function will check for error using `errno` 
then? Since we aren't using the CRT anymore, we might need to map some Windows 
errors to errno...


- Akash Gupta


On April 4, 2018, 5:50 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66432/
> ---
> 
> (Updated April 4, 2018, 5:50 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8676
> https://issues.apache.org/jira/browse/MESOS-8676
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This can eventually support overlapped I/O.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/write.hpp 
> 71006489918d9495d37d2fdfdca08b40b419481a 
> 
> 
> Diff: https://reviews.apache.org/r/66432/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66431: Windows: Fixed `os::read()` to use `ReadFile()`.

[Akash Gupta]

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




3rdparty/stout/include/stout/os/windows/read.hpp
Lines 43 (patched)


Do you know why the return value is `ssize_t` instead of a `Try`. 
Is it due to it being async signal safe?

I imagine the callers of this function will check for error using `errno` 
then? Since we aren't using the CRT anymore, we might need to map some Windows 
errors to errno...


- Akash Gupta


On April 4, 2018, 7:13 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66431/
> ---
> 
> (Updated April 4, 2018, 7:13 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8676
> https://issues.apache.org/jira/browse/MESOS-8676
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This can eventually support overlapped I/O.
> 
> The Windows API `ReadFile()` returns an error if the pipe is broken,
> where `_read()` did not, but this is not an error for us as the data
> is still read correctly. So we ignore it.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/read.hpp 
> 8047ad590fcc46d3ec46b551472d8c518ae49cc1 
> 
> 
> Diff: https://reviews.apache.org/r/66431/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66455: Windows: Fixed `os::ftruncate()` to use `SetEndOfFile()`.

[Andrew Schwartzmeyer]

> On April 5, 2018, 4:45 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/ftruncate.hpp
> > Line 36 (original), 41 (patched)
> > 
> >
> > ftruncate doesn't change the file offset, so make sure you store the 
> > original file offset and restore it. It's currently setting it to the eof 
> > of the new file.

> The file offset is not changed.

Indeed, good catch.


- Andrew


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


On April 4, 2018, 12:16 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66455/
> ---
> 
> (Updated April 4, 2018, 12:16 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8692
> https://issues.apache.org/jira/browse/MESOS-8692
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This previously used the CRT API `_chsize_s()`, which required a CRT
> integer file descriptor. Instead, we can achieve the same behavior by
> first using `os::lseek()` (which uses `SetFilePointerEx()`) to seek
> `length`, and then use `SetEndOfFile()` to truncate. The only
> difference is that the file is not filled with null bytes when
> expanded, but we do not seem to rely on this behavior.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/ftruncate.hpp 
> fc4a8b5040d56fa9766687e44ce17fbe47d9e8f0 
> 
> 
> Diff: https://reviews.apache.org/r/66455/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66430: Windows: Fixed `os::dup()` to use `DuplicateHandle()`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:50 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66430/
> ---
> 
> (Updated April 4, 2018, 5:50 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8684
> https://issues.apache.org/jira/browse/MESOS-8684
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Note that for now we need to keep the original CRT code, as it can't
> be removed until `FD_CRT` is removed too.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/dup.hpp 
> 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 
> 
> 
> Diff: https://reviews.apache.org/r/66430/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66429: Windows: Deleted dead code from `process::internal` namespace.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 7:17 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66429/
> ---
> 
> (Updated April 4, 2018, 7:17 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The deleted code was purely self-referential.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/subprocess_windows.cpp 
> 1a91fbe7aeb44174ccfa2e7e299bc7dd52a11b8a 
> 
> 
> Diff: https://reviews.apache.org/r/66429/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66455: Windows: Fixed `os::ftruncate()` to use `SetEndOfFile()`.

[Akash Gupta]

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




3rdparty/stout/include/stout/os/windows/ftruncate.hpp
Lines 34 (patched)


I think Windows treats the "logical" file as zero-extended due to security 
reasons; it just doesn't actually write the 0s on disk. So, if you try reading 
from the extended region, you will get zeros.

The only difference would be if you try seeking far into the extended 
region and then trying to write something. That `WriteFile` operation could 
take a lot of time, because it has to zero fill the previous bytes & write to 
disk.



3rdparty/stout/include/stout/os/windows/ftruncate.hpp
Line 36 (original), 41 (patched)


ftruncate doesn't change the file offset, so make sure you store the 
original file offset and restore it. It's currently setting it to the eof of 
the new file.


- Akash Gupta


On April 4, 2018, 7:16 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66455/
> ---
> 
> (Updated April 4, 2018, 7:16 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8692
> https://issues.apache.org/jira/browse/MESOS-8692
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This previously used the CRT API `_chsize_s()`, which required a CRT
> integer file descriptor. Instead, we can achieve the same behavior by
> first using `os::lseek()` (which uses `SetFilePointerEx()`) to seek
> `length`, and then use `SetEndOfFile()` to truncate. The only
> difference is that the file is not filled with null bytes when
> expanded, but we do not seem to rely on this behavior.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/ftruncate.hpp 
> fc4a8b5040d56fa9766687e44ce17fbe47d9e8f0 
> 
> 
> Diff: https://reviews.apache.org/r/66455/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66347: Added a test for killing executor during task launch.

[Greg Mann]

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




src/tests/slave_tests.cpp
Lines 5668-5673 (patched)


This test is flaky because the scheduler is started before the 'subscribed' 
expectation is registered. We should start the scheduler after these 
expectations.


- Greg Mann


On April 5, 2018, 10:52 p.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66347/
> ---
> 
> (Updated April 5, 2018, 10:52 p.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This test verifies that when agent shuts down a running
> executor, launching tasks on the agent that use the same
> executor will be dropped properly.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66347/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Review Request 66481: Converted `pid` in command executor to `Option`.

[Zhitao Li]

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

Review request for mesos, Andrew Schwartzmeyer and James Peach.


Repository: mesos


Description
---

This avoids unix's assumption that `pid_t` is a signed integer (which is
not the case on Windows) and explicitly shows whether a pid has been
assigned from launching.

We also changed the member variable to `pid_` to avoid variable
shadowing in `reaped` method.


Diffs
-

  src/launcher/executor.cpp 383655230fcdad30b652ea984cb9f5fc9c49dd38 


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


Testing
---

`make` on Linux.


Thanks,

Zhitao Li

Re: Review Request 66428: Windows: Fixed `os::lseek()` to use `SetFilePointerEx()`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:49 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66428/
> ---
> 
> (Updated April 4, 2018, 5:49 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8685
> https://issues.apache.org/jira/browse/MESOS-8685
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Note the TODO, we may want to synchronize this code later.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/lseek.hpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66428/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Andrew Schwartzmeyer]

> On April 5, 2018, 4:07 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/mktemp.hpp
> > Line 54 (original), 54 (patched)
> > 
> >
> > Huh that's a strange function. Seems like it can cause time check/use 
> > race conditions. We probably want to replace this with the native temp 
> > directory functions in the future.

Ha, I agree. It's listed in MESOS-8682 so it'll get done eventually.


> On April 5, 2018, 4:07 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/open.hpp
> > Lines 37 (patched)
> > 
> >
> > I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC.

It's... similar, but I looked at the use-cases and I think we're more likely to 
introduce unintended behaior by trying to guess what the user wants here.


> On April 5, 2018, 4:07 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/open.hpp
> > Lines 45 (patched)
> > 
> >
> > I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to 
> > inherit from the parent directory / access token. We should ask around on 
> > what's the proper settings for security.

Don't let me forget to file/update/mention the permissions issue.


> On April 5, 2018, 4:07 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/open.hpp
> > Lines 61 (patched)
> > 
> >
> > It's up to you, but I find it clearer to have a switch statement on the 
> > bitfields like this:
> > ```
> > switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) {
> >   case O_RDONLY:
> >   case O_WRONLY:
> >   case O_RDWR:
> >   default:
> > }
> > ```

Only problem is that O_RDONLY is 0, so case O_RDONLY will never execute. Some 
brilliant programmer somewhere though that 0 would work great as a bit flag.


> On April 5, 2018, 4:07 p.m., Akash Gupta wrote:
> > 3rdparty/stout/include/stout/os/windows/open.hpp
> > Lines 73 (patched)
> > 
> >
> > Same thing as above. I think it's more import on this one because 
> > there's techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX 
> > and Windows only have defined behavior for 5 of them, so you can explicitly 
> > mention the undefined behavior cases like this:
> > 
> > ```
> > switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) {
> >   case O_CREAT | O_EXCL:
> >   case O_CREAT | O_EXCL | O_TRUNC :
> >// Ignore O_TRUNC if we get O_CREAT | O_EXCL
> >create = CREATE_NEW; break;
> >   case ...:
> > }

Yeah I was not a huge fan of these if/else chains. Thanks.


- Andrew


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


On April 3, 2018, 10:47 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 3, 2018, 10:47 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Andrew Schwartzmeyer]

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




3rdparty/stout/include/stout/os/windows/open.hpp
Lines 37 (patched)


It's... similar, but I looked at the use-cases and I think we're more 
likely to introduce unintended behaior by trying to guess what the user wants 
here.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 61 (patched)


Only problem is that `O_RDONLY` is 0, so `case O_RDONLY` will never 
execute. Some brilliant programmer somewhere though that `0` would work great 
as a bit flag.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 73 (patched)


Yeah I was not a huge fan of these if/else chains. Thanks.


- Andrew Schwartzmeyer


On April 3, 2018, 10:47 p.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 3, 2018, 10:47 p.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66427: Split `stout/os/lseek.hpp` into Windows and POSIX files.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:48 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66427/
> ---
> 
> (Updated April 4, 2018, 5:48 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8685
> https://issues.apache.org/jira/browse/MESOS-8685
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Split `stout/os/lseek.hpp` into Windows and POSIX files.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/Makefile.am 742bfc44d68d978dd2249ece500d6f64e4d7f02a 
>   3rdparty/stout/include/stout/os/lseek.hpp 
> 77fe272afc89f41836c2540de42135dc364917ce 
>   3rdparty/stout/include/stout/os/posix/lseek.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/lseek.hpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66427/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66426: Windows: More constness in stout.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:48 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66426/
> ---
> 
> (Updated April 4, 2018, 5:48 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Also small fixes such as `reserve` over an allocation, and a bad name
> `si` instead of `info`.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/getcwd.hpp 
> f316d618226872b57d950b468352176a7a0cb45a 
>   3rdparty/stout/include/stout/os/windows/getenv.hpp 
> 58012e03aca5dfa2f65fc183b21533dd0ed91d8d 
>   3rdparty/stout/include/stout/os/windows/jobobject.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/killtree.hpp 
> ce8bdcd18305ffb758f22a6c2bbc7393675aebdf 
>   3rdparty/stout/include/stout/os/windows/mkdir.hpp 
> 8d8d80bee77253086939c28333b0413bd8b8b8b6 
>   3rdparty/stout/include/stout/os/windows/pagesize.hpp 
> ddf23c1c5d15c1dd7de37e98673b70836a0e2c5c 
>   3rdparty/stout/include/stout/os/windows/realpath.hpp 
> c6bad5063c8d8255b29a3a6cb9ea51e13c42275c 
>   3rdparty/stout/include/stout/os/windows/su.hpp 
> 1bfbb261edbd25b4552742fc0597e331012cad98 
>   3rdparty/stout/include/stout/os/windows/temp.hpp 
> 9cf467fd9358cc4de702e0501263abcd28a0fa8c 
> 
> 
> Diff: https://reviews.apache.org/r/66426/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66425: Windows: Replaced `WindowsFD` with `int_fd` typedef.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66425/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8682
> https://issues.apache.org/jira/browse/MESOS-8682
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The latter should be used everywhere but in the implementation for
> consistency with the POSIX side of the code.
> 
> Also meant fixing the included header (and spacing).
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/internal/windows/inherit.hpp 
> 6da6f8eb1382d226c8b16a8e4cbb454205ef4045 
>   3rdparty/stout/include/stout/os/windows/close.hpp 
> ff635e44235d63888a210cd68d49f6678a851e31 
>   3rdparty/stout/include/stout/os/windows/dup.hpp 
> 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/fsync.hpp 
> 8405247280b51e74a172317816096ca77fdfd1e7 
>   3rdparty/stout/include/stout/os/windows/ftruncate.hpp 
> fc4a8b5040d56fa9766687e44ce17fbe47d9e8f0 
>   3rdparty/stout/include/stout/os/windows/pipe.hpp 
> 365db9480f6258a03ef2e760a19abef8ab177e58 
>   3rdparty/stout/include/stout/os/windows/read.hpp 
> 8047ad590fcc46d3ec46b551472d8c518ae49cc1 
>   3rdparty/stout/include/stout/os/windows/sendfile.hpp 
> fff5872db6b3f69464e41e6d108a107e4eeabd12 
>   3rdparty/stout/include/stout/os/windows/shell.hpp 
> aacd746922495f994891aa85d3e4fa95e2bd1c44 
>   3rdparty/stout/include/stout/os/windows/socket.hpp 
> 259b05b8c85e399feaccec698d58b7d540cad368 
>   3rdparty/stout/include/stout/os/windows/write.hpp 
> 71006489918d9495d37d2fdfdca08b40b419481a 
>   3rdparty/stout/include/stout/windows/os.hpp 
> 739ee4da3f09d2a9597d4451e755e77903e9287d 
> 
> 
> Diff: https://reviews.apache.org/r/66425/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/windows/mktemp.hpp
Line 54 (original), 54 (patched)


Huh that's a strange function. Seems like it can cause time check/use race 
conditions. We probably want to replace this with the native temp directory 
functions in the future.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 33 (patched)


:)



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 37 (patched)


I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 45 (patched)


I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to inherit 
from the parent directory / access token. We should ask around on what's the 
proper settings for security.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 61 (patched)


It's up to you, but I find it clearer to have a switch statement on the 
bitfields like this:
```
switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) {
  case O_RDONLY:
  case O_WRONLY:
  case O_RDWR:
  default:
}
```



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 73 (patched)


Same thing as above. I think it's more import on this one because there's 
techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX and Windows 
only have defined behavior for 5 of them, so you can explicitly mention the 
undefined behavior cases like this:

```
switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) {
  case O_CREAT | O_EXCL:
  case O_CREAT | O_EXCL | O_TRUNC :
   // Ignore O_TRUNC if we get O_CREAT | O_EXCL
   create = CREATE_NEW; break;
  case ...:
}


- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/windows/mktemp.hpp
Line 54 (original), 54 (patched)


Huh that's a strange function. Seems like it can cause time check/use race 
conditions. We probably want to replace this with the native temp directory 
functions in the future.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 33 (patched)


:)



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 37 (patched)


I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 45 (patched)


I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to inherit 
from the parent directory / access token. We should ask around on what's the 
proper settings for security.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 61 (patched)


It's up to you, but I find it clearer to have a switch statement on the 
bitfields like this:
```
switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) {
  case O_RDONLY:
  case O_WRONLY:
  case O_RDWR:
  default:
}
```



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 73 (patched)


Same thing as above. I think it's more import on this one because there's 
techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX and Windows 
only have defined behavior for 5 of them, so you can explicitly mention the 
undefined behavior cases like this:

```
switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) {
  case O_CREAT | O_EXCL:
  case O_CREAT | O_EXCL | O_TRUNC :
   // Ignore O_TRUNC if we get O_CREAT | O_EXCL
   create = CREATE_NEW; break;
  case ...:
}


- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/windows/mktemp.hpp
Line 54 (original), 54 (patched)


Huh that's a strange function. Seems like it can cause time check/use race 
conditions. We probably want to replace this with the native temp directory 
functions in the future.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 33 (patched)


:)



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 37 (patched)


I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 45 (patched)


I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to inherit 
from the parent directory / access token. We should ask around on what's the 
proper settings for security.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 61 (patched)


It's up to you, but I find it clearer to have a switch statement on the 
bitfields like this:
```
switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) {
  case O_RDONLY:
  case O_WRONLY:
  case O_RDWR:
  default:
}
```



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 73 (patched)


Same thing as above. I think it's more import on this one because there's 
techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX and Windows 
only have defined behavior for 5 of them, so you can explicitly mention the 
undefined behavior cases like this:

```
switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) {
  case O_CREAT | O_EXCL:
  case O_CREAT | O_EXCL | O_TRUNC :
   // Ignore O_TRUNC if we get O_CREAT | O_EXCL
   create = CREATE_NEW; break;
  case ...:
}


- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66424: Windows: Replaced `_wopen()` with `CreateFileW()` in `os::open()`.

[Akash Gupta]

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


Fix it, then Ship it!





3rdparty/stout/include/stout/os/windows/mktemp.hpp
Line 54 (original), 54 (patched)


Huh that's a strange function. Seems like it can cause time check/use race 
conditions. We probably want to replace this with the native temp directory 
functions in the future.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 33 (patched)


:)



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 37 (patched)


I *think* FILE_FLAG_WRITE_THROUGH == O_SYNC.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 45 (patched)


I believe the default behavior(`SECURITY_ATTRIBUTES == NULL`) is to inherit 
from the parent directory / access token. We should ask around on what's the 
proper settings for security.



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 61 (patched)


It's up to you, but I find it clearer to have a switch statement on the 
bitfields like this:
```
switch(oflag & (O_RDONLY | O_WRONLY | O_RDWR)) {
  case O_RDONLY:
  case O_WRONLY:
  case O_RDWR:
  default:
}
```



3rdparty/stout/include/stout/os/windows/open.hpp
Lines 73 (patched)


Same thing as above. I think it's more import on this one because there's 
techically 8 cases for `O_CREAT`, `O_EXCL`, `O_TRUNC`, but POSIX and Windows 
only have defined behavior for 5 of them, so you can explicitly mention the 
undefined behavior cases like this:

```
switch(oflag & (O_CREAT | O_EXCL | O_TRUNC)) {
  case O_CREAT | O_EXCL:
  case O_CREAT | O_EXCL | O_TRUNC :
   // Ignore O_TRUNC if we get O_CREAT | O_EXCL
   create = CREATE_NEW; break;
  case ...:
}


- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66424/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Instead of using the CRT implementation of `_wopen()` for the
> `os::open()` API, we now use the Windows API `CreateFileW()`, mapping
> each of the Linux `open()` flags to their semantic equivalents. This
> will make implementing overlapped I/O possible, and is a step toward
> removing the use of integer file descriptors on Windows.
> 
> Note that instead of redefining the C flags like `O_RDONLY`, we just
> use them directly in our mapping logic, and set the used but
> unsupported flags to zero.
> 
> This change uncovered several bugs such as incorrect access flags, and
> used-but-not-included headers.
> 
> We currently ignore creation permissions as they will be handled in a
> broader project to map permissions to Windows correctly.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/net.hpp 
> d2992c05b221ea90dae1c06d27753932f7411925 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/mktemp.hpp 
> 5c775c45c415d9ddd6a80ab814fb55475e9f871e 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/windows.hpp 
> 1bfcdf4a5c097cc6d2293396ce39c8ad2c9ec993 
> 
> 
> Diff: https://reviews.apache.org/r/66424/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66347: Added a test for killing executor during task launch.

[Meng Zhu]

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

(Updated April 5, 2018, 3:52 p.m.)


Review request for mesos and Greg Mann.


Changes
---

Rebase.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

This test verifies that when agent shuts down a running
executor, launching tasks on the agent that use the same
executor will be dropped properly.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66347/diff/5/

Changes: https://reviews.apache.org/r/66347/diff/4-5/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 66458: Fixed handling of operations in `master::recoverFramework()`.

[Greg Mann]

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


Ship it!




Ship It!

- Greg Mann


On April 4, 2018, 11:47 p.m., Gaston Kleiman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66458/
> ---
> 
> (Updated April 4, 2018, 11:47 p.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> `Master::recoverFramework()` only recovers operations affecting agent
> default resources. This patch makes it also recover operations affecting
> resources managed by resource providers.
> 
> It also fixes a bug in which not just the corresponding operations, but
> all the ones affecting agent default resources will be added to the
> framework.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp 18382fa93fd0c59e641e00f2028ac1ae2e67c01c 
> 
> 
> Diff: https://reviews.apache.org/r/66458/diff/1/
> 
> 
> Testing
> ---
> 
> `sudo bin/mesos-tests` on GNU/Linux
> 
> 
> Thanks,
> 
> Gaston Kleiman
> 
>

Re: Review Request 66145: Added a test to verify that task launch order is enforced.

[Meng Zhu]

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

(Updated April 5, 2018, 3:38 p.m.)


Review request for mesos, Chun-Hung Hsiao and Greg Mann.


Changes
---

Rebase.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

Agent should launch the task in their receiving order.
On the task launch path, there are currently two
asynchronous steps which may complete out of order:
unschedule GC and task authorization.

This test simulates the reordering of the completions
of unschedule GC step and verify that, despite the
reordering, tasks can still launch in their original order.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66145/diff/9/

Changes: https://reviews.apache.org/r/66145/diff/8-9/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 66126: Refactored agent task launch for better composition [1/2].

[Meng Zhu]

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

(Updated April 5, 2018, 3:35 p.m.)


Review request for mesos, Chun-Hung Hsiao and Greg Mann.


Changes
---

Minor fix.


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

This helps to encapsulate a task launch into a single
future which will come in handy when enforcing the task
launch order.

This patch also consolidated the error handling code
in the task launch path.

Affected tests are also updated.


Diffs (updated)
-

  src/slave/slave.hpp 37f0361251524e63d02d251e8a03901812b8affb 
  src/slave/slave.cpp b17854788ceb63f3748380c546a13531e86f0dda 
  src/tests/mock_slave.hpp 8ec2b65a75f774d970ef6507df8b0c02fda5f2fd 
  src/tests/mock_slave.cpp 8ec55b6aa84dd8b1c3743cbcdc246311585d0f63 
  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66126/diff/8/

Changes: https://reviews.apache.org/r/66126/diff/7-8/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 65679: Removed direct unmock calls and added missing mock call expectations.

[Meng Zhu]

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

(Updated April 5, 2018, 3:35 p.m.)


Review request for mesos, Chun-Hung Hsiao and Greg Mann.


Changes
---

Added additional fix for `RemoveExecutorUponFailedLaunch`


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


Repository: mesos


Description
---

Directly invoking unmock calls in the test process can potentially
cause races with the real mock slave process. It is more robust to
dispatch the unmock calls to the real mock slave process.

Also added several mock expectations to avoid "uninteresting mock
call" test warnings.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/65679/diff/10/

Changes: https://reviews.apache.org/r/65679/diff/9-10/


Testing
---

`./bin/mesos-tests.sh --gtest_filter=*SlaveTest* --gtest_repeat=-1 
--gtest_break_on_failure` runs forever :)


Thanks,

Meng Zhu

Re: Review Request 66347: Added a test for killing executor during task launch.

[Greg Mann]

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


Ship it!




Ship It!

- Greg Mann


On April 5, 2018, 4:08 p.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66347/
> ---
> 
> (Updated April 5, 2018, 4:08 p.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This test verifies that when agent shuts down a running
> executor, launching tasks on the agent that use the same
> executor will be dropped properly.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66347/diff/4/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Re: Review Request 66323: Added tests for failed task launch on agent.

[Greg Mann]

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




src/tests/slave_tests.cpp
Lines 5407 (patched)


Capture by value. Here and below.



src/tests/slave_tests.cpp
Lines 5609 (patched)


Capture by value.


- Greg Mann


On April 4, 2018, 3:32 a.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66323/
> ---
> 
> (Updated April 4, 2018, 3:32 a.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> These tests verify the agent behavior of launching
> several task groups using the same executor. When
> task groups are launching on the agent (before creating
> any executor), if the first received task group
> fails to launch, later task groups will get dropped.
> If a later received task group fails to launch, the first
> received task group should still launch successfully.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66323/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Re: Review Request 66323: Added tests for failed task launch on agent.

[Greg Mann]

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


Ship it!




Ship It!

- Greg Mann


On April 4, 2018, 3:32 a.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66323/
> ---
> 
> (Updated April 4, 2018, 3:32 a.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> These tests verify the agent behavior of launching
> several task groups using the same executor. When
> task groups are launching on the agent (before creating
> any executor), if the first received task group
> fails to launch, later task groups will get dropped.
> If a later received task group fails to launch, the first
> received task group should still launch successfully.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66323/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Re: Review Request 66423: Split `stout/os/open.hpp` into Windows and POSIX files.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66423/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8673
> https://issues.apache.org/jira/browse/MESOS-8673
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The logic remained the same, just with the Windows code removed from
> the POSIX code, and vice versa.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/Makefile.am 742bfc44d68d978dd2249ece500d6f64e4d7f02a 
>   3rdparty/stout/include/stout/os/open.hpp 
> 4dc5b087abf40ac9b81f0fd611aca192e5d33ce7 
>   3rdparty/stout/include/stout/os/posix/open.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/open.hpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/66423/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66422: Windows: Included used `jobobject.hpp` stout header in Mesos.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66422/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The job object functions were refactored upstream from
> `windows/os.hpp` to `os/windows/jobobject.hpp`.
> 
> 
> Diffs
> -
> 
>   src/launcher/executor.cpp 383655230fcdad30b652ea984cb9f5fc9c49dd38 
>   src/slave/containerizer/mesos/isolators/windows/cpu.cpp 
> 69b0ff8ab1c391c8771954de64a17b6ad1c5c10c 
>   src/slave/containerizer/mesos/isolators/windows/mem.cpp 
> 6cc65b942fd7d11d2ea35eab0225427ffdd9d1ee 
>   src/slave/containerizer/mesos/launch.cpp 
> 8c739ccd39675d5417437609a31f5a21784535b7 
> 
> 
> Diff: https://reviews.apache.org/r/66422/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66421: Windows: Included used `jobobject.hpp` stout header in libprocess.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:47 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66421/
> ---
> 
> (Updated April 4, 2018, 5:47 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The job object functions were refactored upstream from
> `windows/os.hpp` to `os/windows/jobobject.hpp`.
> 
> Also removed `windows/os.hpp` because `os.hpp` includes it for us.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/include/process/windows/jobobject.hpp 
> 0de374d374804c2d4f06a352d80062d3b42ed9b2 
> 
> 
> Diff: https://reviews.apache.org/r/66421/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66420: Windows: Extracted job object code into `os/windows/jobobject.hpp`.

[Akash Gupta]

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


Ship it!




Ship It!

- Akash Gupta


On April 4, 2018, 5:46 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66420/
> ---
> 
> (Updated April 4, 2018, 5:46 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The functions written to deal with job objects on Windows had become
> large enough to warrant being refactored into their own file. Also
> was the perfect opportunity to fix formatting issues.
> 
> When including `jobobject.hpp` for `killtree.hpp`, other unnecessary
> headers were removed.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/Makefile.am 742bfc44d68d978dd2249ece500d6f64e4d7f02a 
>   3rdparty/stout/include/stout/os/windows/jobobject.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/killtree.hpp 
> ce8bdcd18305ffb758f22a6c2bbc7393675aebdf 
>   3rdparty/stout/include/stout/windows/os.hpp 
> 739ee4da3f09d2a9597d4451e755e77903e9287d 
> 
> 
> Diff: https://reviews.apache.org/r/66420/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 66384: Link libm in ZooKeeper build on FreeBSD.

[Andrew Schwartzmeyer]

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


Ship it!




Ship It!

- Andrew Schwartzmeyer


On April 5, 2018, 11:41 a.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66384/
> ---
> 
> (Updated April 5, 2018, 11:41 a.m.)
> 
> 
> Review request for mesos and Andrew Schwartzmeyer.
> 
> 
> Bugs: MESOS-4176
> https://issues.apache.org/jira/browse/MESOS-4176
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Link libm in ZooKeeper build on FreeBSD.
> 
> 
> Diffs
> -
> 
>   3rdparty/zookeeper-3.4.8.patch 2eaa056dd5668d5842b5b59a42f83ae307d4aef0 
> 
> 
> Diff: https://reviews.apache.org/r/66384/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66392: Find sasl2 on non-Windows platforms before trying to link it.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66384, 66385, 66387, 66392]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 5, 2018, 11:41 a.m., David Forsythe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66392/
> ---
> 
> (Updated April 5, 2018, 11:41 a.m.)
> 
> 
> Review request for mesos and Andrew Schwartzmeyer.
> 
> 
> Bugs: MESOS-4176
> https://issues.apache.org/jira/browse/MESOS-4176
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Find sasl2 on non-Windows platforms before trying to link it.
> 
> 
> Diffs
> -
> 
>   3rdparty/CMakeLists.txt 9d0fd552a15387754fb7a27256308ef8beb1e3ed 
> 
> 
> Diff: https://reviews.apache.org/r/66392/diff/4/
> 
> 
> Testing
> ---
> 
> make on FreeBSD
> 
> 
> Thanks,
> 
> David Forsythe
> 
>

Re: Review Request 66392: Find sasl2 on non-Windows platforms before trying to link it.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66384', '66385', '66387', '66392']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66392

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66392/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (116 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1101 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (31 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (37 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (72 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (806 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (833 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (736 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (762 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (451009 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66392/logs/mesos-tests-stderr.log):

```
I0405 19:44:58.372272  9320 slave.cpp:3877] Shutting down framework 
92271462-df09-48d2-8671-75f722fd2fb3-
I0405 19:44:58.372272  3620 master.cpp:10449] Updating the state of task 
d1f2deb2-6fa6-4976-8a65-d5b3e3c7b546 of framework 
92271462-df09-48d2-8671-75f722fd2fb3- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0405 19:44:58.372272  9320 slave.cpp:6574] Shutting down executor 
'd1f2deb2-6fa6-4976-8a65-d5b3e3c7b546' of framework 
92271462-df09-48d2-8671-75f722fd2fb3- at executor(1)@10.3.1.8:49504
I040I0405 19:44:58.190281 10276 exec.cpp:162] Version: 1.6.0
I0405 19:44:58.215250 16356 exec.cpp:236] Executor registered on agent 
92271462-df09-48d2-8671-75f722fd2fb3-S0
I0405 19:44:58.220269 16440 executor.cpp:176] Received SUBSCRIBED event
I0405 19:44:58.225286 16440 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0405 19:44:58.226286 16440 executor.cpp:176] Received LAUNCH event
I0405 19:44:58.230286 16440 executor.cpp:648] Starting task 
d1f2deb2-6fa6-4976-8a65-d5b3e3c7b546
I0405 19:44:58.313284 16440 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0405 19:44:58.342264 16440 executor.cpp:661] Forked command at 5796
I0405 19:44:58.373265 17128 exec.cpp:445] Executor asked to shutdown
I0405 19:44:58.374266  8036 executor.cpp:176] Received SHUTDOWN event
I0405 19:44:58.374266  8036 executor.cpp:758] Shutting down
I0405 19:44:58.374266  8036 executor.cpp:868] Sending SIGTERM to process tree 
at pid 55 19:44:58.373265  9320 slave.cpp:923] Agent terminating
W0405 19:44:58.374266  9320 slave.cpp:3873] Ignoring shutdown framework 
92271462-df09-48d2-8671-75f722fd2fb3- because it is terminating
I0405 19:44:58.375288  3620 master.cpp:10548] Removing task 
d1f2deb2-6fa6-4976-8a65-d5b3e3c7b546 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework 92271462-df09-48d2-8671-75f722fd2fb3- on 
agent 92271462-df09-48d2-8671-75f722fd2fb3-S0 at slave(418)@10.3.1.8:49483 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 19:44:58.377274  9320 containerizer.cpp:2338] Destroying container 
126d3f41-81f9-4cc1-8e43-b0a1b015bafc in RUNNING state
I0405 19:44:58.377274  9320 containerizer.cpp:2952] Transitioning the state of 
container 126d3f41-81f9-4cc1-8e43-b0a1b015bafc from RUNNING to DESTROYING
I0405 19:44:58.377274  3620 master.cpp:1295] Agent 
92271462-df09-48d2-8671-75f722fd2fb3-S0 at slave(418)@10.3.1.8:49483 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0405 19:44:58.378263  9320 launcher.cpp:156] Asked to destroy container 
126d3f41-81f9-4cc1-8e43-b0a1b015bafc
I0405 19:44:58.378263  3620 

Re: Review Request 66323: Added tests for failed task launch on agent.

[Meng Zhu]

> On April 3, 2018, 5:17 p.m., Greg Mann wrote:
> > src/tests/slave_tests.cpp
> > Lines 5251-5252 (patched)
> > 
> >
> > Is this needed?
> 
> Meng Zhu wrote:
> To avoid uninteresting mock calls.
> 
> Greg Mann wrote:
> The real question here is WHY does this method get called on the 
> scheduler? The `failure()` method is invoked whenever an `Event::FAILURE` is 
> received by the test v1 scheduler. I didn't realize it, but it turns out we 
> evolve the `ExitedExecutorMessage` into an `Event::FAILURE` for v1 
> schedulers: 
> https://github.com/apache/mesos/blob/594ee20c2453dad836313769aef9f8655cd75cd5/src/internal/evolve.cpp#L294-L305
> 
> So the exiting executor in this test explains why that method is invoked. 
> However, I don't understand why it would be invoked twice, since we only have 
> one executor here? I wonder if we're executing some cleanup logic for the 
> failed task twice? It's also possible that the event is sent when the agent 
> is removed at the end of the test, but I don't recall running into this in 
> other tests.

Changed to `atmost(1)`


- Meng


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


On April 3, 2018, 8:32 p.m., Meng Zhu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66323/
> ---
> 
> (Updated April 3, 2018, 8:32 p.m.)
> 
> 
> Review request for mesos and Greg Mann.
> 
> 
> Bugs: MESOS-8617 and MESOS-8624
> https://issues.apache.org/jira/browse/MESOS-8617
> https://issues.apache.org/jira/browse/MESOS-8624
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> These tests verify the agent behavior of launching
> several task groups using the same executor. When
> task groups are launching on the agent (before creating
> any executor), if the first received task group
> fails to launch, later task groups will get dropped.
> If a later received task group fails to launch, the first
> received task group should still launch successfully.
> 
> 
> Diffs
> -
> 
>   src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 
> 
> 
> Diff: https://reviews.apache.org/r/66323/diff/6/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Meng Zhu
> 
>

Re: Review Request 66387: Link subversion in stout build on FreeBSD.

[David Forsythe]

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

(Updated April 5, 2018, 6:42 p.m.)


Review request for mesos and Andrew Schwartzmeyer.


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


Repository: mesos


Description
---

Link subversion in stout build on FreeBSD.


Diffs (updated)
-

  3rdparty/stout/CMakeLists.txt 5d787d87f0a4b30ba882b24d08118856eb84206b 


Diff: https://reviews.apache.org/r/66387/diff/2/

Changes: https://reviews.apache.org/r/66387/diff/1-2/


Testing
---


Thanks,

David Forsythe

Re: Review Request 66385: Link execinfo in Glog build on FreeBSD.

[David Forsythe]

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

(Updated April 5, 2018, 6:41 p.m.)


Review request for mesos and Andrew Schwartzmeyer.


Bugs: MESOS-4176 and MESOS-6849
https://issues.apache.org/jira/browse/MESOS-4176
https://issues.apache.org/jira/browse/MESOS-6849


Repository: mesos


Description
---

Link execinfo in Glog build on FreeBSD.


Diffs (updated)
-

  3rdparty/CMakeLists.txt 9d0fd552a15387754fb7a27256308ef8beb1e3ed 
  cmake/CompilationConfigure.cmake 64cc56ee4208afe05df0f28af5890157e4c7d82c 


Diff: https://reviews.apache.org/r/66385/diff/3/

Changes: https://reviews.apache.org/r/66385/diff/2-3/


Testing
---


Thanks,

David Forsythe

Re: Review Request 66384: Link libm in ZooKeeper build on FreeBSD.

[David Forsythe]

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

(Updated April 5, 2018, 6:41 p.m.)


Review request for mesos and Andrew Schwartzmeyer.


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


Repository: mesos


Description
---

Link libm in ZooKeeper build on FreeBSD.


Diffs (updated)
-

  3rdparty/zookeeper-3.4.8.patch 2eaa056dd5668d5842b5b59a42f83ae307d4aef0 


Diff: https://reviews.apache.org/r/66384/diff/2/

Changes: https://reviews.apache.org/r/66384/diff/1-2/


Testing
---


Thanks,

David Forsythe

Re: Review Request 66392: Find sasl2 on non-Windows platforms before trying to link it.

[David Forsythe]

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

(Updated April 5, 2018, 6:41 p.m.)


Review request for mesos and Andrew Schwartzmeyer.


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


Repository: mesos


Description
---

Find sasl2 on non-Windows platforms before trying to link it.


Diffs (updated)
-

  3rdparty/CMakeLists.txt 9d0fd552a15387754fb7a27256308ef8beb1e3ed 


Diff: https://reviews.apache.org/r/66392/diff/4/

Changes: https://reviews.apache.org/r/66392/diff/3-4/


Testing
---

make on FreeBSD


Thanks,

David Forsythe

Re: Review Request 66437: Windows: Removed `FD_CRT` from `WindowsFD` abstraction.

[John Kordich via Review Board]

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


Ship it!




This really does feel hacky, but the alternative requires such a significant 
refactoring that it's probably not worth it (potential bug factory) just to get 
this working properly on Windows. I'll hold my nose and sign off.

- John Kordich


On April 5, 2018, 1:58 a.m., Andrew Schwartzmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66437/
> ---
> 
> (Updated April 5, 2018, 1:58 a.m.)
> 
> 
> Review request for mesos, Akash Gupta, Eric Mumau, John Kordich, Joseph Wu, 
> and Michael Park.
> 
> 
> Bugs: MESOS-8675 and MESOS-8683
> https://issues.apache.org/jira/browse/MESOS-8675
> https://issues.apache.org/jira/browse/MESOS-8683
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> After all the CRT APIs were replaced with Windows APIs, we no longer
> needed to support the semantics of an `int` file descriptor in
> general (in the sense of opening a CRT handle that's associated with
> the actual kernel object for the given `HANDLE`). There are specific
> use cases (usually third-party code) which still require a CRT
> int-like file descriptor, which the `crt()` function explicitly
> allocates (this allocation used to be done in the constructor).
> 
> Thus the entire `FD_CRT` type was removed from the `WindowsFD`
> abstraction. It still acts like an `int` in the sense that it can be
> constructed from one and compared to one. However, construction via
> `int` only supports the standard file descriptors 0, 1, and 2 for
> `stdin`, `stdout`, and `stderr`. Any other construction creates an
> `int_fd` which holds an `INVALID_HANDLE` value. When being compared to
> an `int`, the abstraction simply returns -1 if it is invalid (based on
> the result of the `is_valid()` method) or 0 if it is valid. This is to
> support the semantics of checking validity by something like `if (fd <
> 0)` or `if (fd == -1)`.
> 
> With the deletion of the `FD_CRT` type from `WindowsFD`, all the Stout
> APIs that switched on the type were simplified, with the last of the
> CRT code deleted.
> 
> Thanks to the introduction of the private `int get_valid()` function,
> and the removal of the `FD_CRT` type, the comparison operators became
> much simpler.
> 
> 
> Diffs
> -
> 
>   3rdparty/stout/include/stout/os/windows/close.hpp 
> ff635e44235d63888a210cd68d49f6678a851e31 
>   3rdparty/stout/include/stout/os/windows/dup.hpp 
> 265046cf7ffc14f7326711d295aa7dd4f0a8a1e3 
>   3rdparty/stout/include/stout/os/windows/fcntl.hpp 
> bf8c38acad60f9b0eb752053dcd53a9fda7b8bfa 
>   3rdparty/stout/include/stout/os/windows/fd.hpp 
> d7f8cdf1ad877eb55589bf5a9e75d295f91990a7 
>   3rdparty/stout/include/stout/os/windows/read.hpp 
> 8047ad590fcc46d3ec46b551472d8c518ae49cc1 
>   3rdparty/stout/include/stout/os/windows/write.hpp 
> 71006489918d9495d37d2fdfdca08b40b419481a 
>   3rdparty/stout/tests/os/filesystem_tests.cpp 
> c190baa2230298e428d4034b90dccffb59b4e710 
> 
> 
> Diff: https://reviews.apache.org/r/66437/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrew Schwartzmeyer
> 
>

Re: Review Request 65940: Added test validating hierarchical role accounting.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['65939', '65940']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/65940

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/65940/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (122 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1097 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (34 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (39 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (76 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (806 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (832 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (830 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (856 ms total)

[--] Global test environment tear-down
[==] 952 tests from 94 test cases ran. (450674 ms total)
[  PASSED  ] 951 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/65940/logs/mesos-tests-stderr.log):

```
I0405 17:16:48.497124 16908 slave.cpp:3877] Shutting down framework 
162365de-1c49-4761-b1e9-1f6c7I0405 17:16:48.303117 12204 exec.cpp:162] Version: 
1.6.0
I0405 17:16:48.328111 17380 exec.cpp:236] Executor registered on agent 
162365de-1c49-4761-b1e9-1f6c706fc1ab-S0
I0405 17:16:48.332118  3252 executor.cpp:176] Received SUBSCRIBED event
I0405 17:16:48.337119  3252 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0405 17:16:48.338119  3252 executor.cpp:176] Received LAUNCH event
I0405 17:16:48.347120  3252 executor.cpp:648] Starting task 
c3ca2630-98c5-4529-a2f3-a882b7fc13a3
I0405 17:16:48.438122  3252 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0405 17:16:48.469312  3252 executor.cpp:661] Forked command at 16076
I0405 17:16:48.500109  6336 exec.cpp:445] Executor asked to shutdown
I0405 17:16:48.500109  7048 executor.cpp:176] Received SHUTDOWN event
I0405 17:16:48.500109  7048 executor.cpp:758] Shutting down
I0405 17:16:48.500109  7048 executor.cpp:868] Sending SIGTERM to process tree 
at pid 06fc1ab-
I0405 17:16:48.497124 11856 master.cpp:10617] Updating the state of task 
c3ca2630-98c5-4529-a2f3-a882b7fc13a3 of framework 
162365de-1c49-4761-b1e9-1f6c706fc1ab- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0405 17:16:48.498112 16908 slave.cpp:6574] Shutting down executor 
'c3ca2630-98c5-4529-a2f3-a882b7fc13a3' of framework 
162365de-1c49-4761-b1e9-1f6c706fc1ab- at executor(1)@10.3.1.8:61555
I0405 17:16:48.499109 16900 slave.cpp:923] Agent terminating
W0405 17:16:48.499109 16900 slave.cpp:3873] Ignoring shutdown framework 
162365de-1c49-4761-b1e9-1f6c706fc1ab- because it is terminating
I0405 17:16:48.502121 11856 master.cpp:10716] Removing task 
c3ca2630-98c5-4529-a2f3-a882b7fc13a3 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework 162365de-1c49-4761-b1e9-1f6c706fc1ab- on 
agent 162365de-1c49-4761-b1e9-1f6c706fc1ab-S0 at slave(421)@10.3.1.8:61534 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 17:16:48.502121  6892 containerizer.cpp:2338] Destroying container 
6b754c01-482d-4a91-b7aa-e58e559ac9cd in RUNNING state
I0405 17:16:48.503108  6892 containerizer.cpp:2952] Transitioning the state of 
container 6b754c01-482d-4a91-b7aa-e58e559ac9cd from RUNNING to DESTROYING
I0405 17:16:48.504112  6892 launcher.cpp:156] Asked to destroy container 
6b754c01-482d-4a91-b7aa-e58e559ac9cd
I0405 17:16:48.506127 11856 master.cpp:1463] Agent 
162365de-1c49-4761-b1e9-1f6c706fc1ab-S0 at slave(421)@10.3.1.8:61534 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0405 17:16:48.506127 11856 master.cpp:3454] Disconnecting 

Re: Review Request 66476: Tightened resource provider manager registrar tests.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66476]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 5, 2018, 2:14 p.m., Benjamin Bannier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66476/
> ---
> 
> (Updated April 5, 2018, 2:14 p.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Jan Schlicht.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch changes tests of operations on the resource provider
> manager registrar to make the operations return with a success instead
> of just checking that the future results get ready.
> 
> 
> Diffs
> -
> 
>   src/tests/resource_provider_manager_tests.cpp 
> 05ae5defb986103520cf630d5578e8a04e662313 
> 
> 
> Diff: https://reviews.apache.org/r/66476/diff/1/
> 
> 
> Testing
> ---
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Re: Review Request 65939: Updated role endpoints for hierarchical accounting.

[Till Toenshoff]

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

(Updated April 5, 2018, 4:15 p.m.)


Review request for mesos, Benjamin Bannier, Benjamin Mahler, Kapil Arya, 
Michael Park, and Meng Zhu.


Changes
---

Switched from snapshot view towards constant master owned hierarchical roles 
bookkeeping. Added `total_frameworks` as another inherited role attribute.


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


Repository: mesos


Description (updated)
---

When listing role "a", resources allocated to role "a/b" are added to
those allocated to role "a". These changes affect both, the "/roles"
endpoint as well as the V1 HTTP Call "GET_ROLES".
Adds dynamic hierarchical role tracking to the master.


Diffs (updated)
-

  include/mesos/mesos.proto 676f0b090cad7ebf59eb32556f17ff8b5f247907 
  include/mesos/v1/master/master.proto ddb28f96b2a3a439bb9a829995a9a3015f65ba43 
  include/mesos/v1/mesos.proto 10d506517c9f098374ab0c8f4dcfda42e1896c95 
  src/master/http.cpp 34c9023906eca94965acc994f20e888c1f47b962 
  src/master/master.hpp 0d9620dd0c232dc1df83477e838eeb7313bf8828 
  src/master/master.cpp 18382fa93fd0c59e641e00f2028ac1ae2e67c01c 
  src/master/quota_handler.cpp 21bafd0064e9397f88185eaf687a58f85da94e2c 
  src/master/weights_handler.cpp 1053652804a8fc6af31a3b8a9f632f836c897fa9 
  src/tests/api_tests.cpp dd8e221d8fd1b2a241505345337897e4ee4a6347 
  src/tests/role_tests.cpp a609ed27ef828ca82efc0d269669cda92e5f50a1 


Diff: https://reviews.apache.org/r/65939/diff/2/

Changes: https://reviews.apache.org/r/65939/diff/1-2/


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 65940: Added test validating hierarchical role accounting.

[Till Toenshoff]

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

(Updated April 5, 2018, 4:15 p.m.)


Review request for mesos, Benjamin Bannier, Benjamin Mahler, Kapil Arya, and 
Michael Park.


Changes
---

Added unversioned API `/roles`-endpoint test.


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


Repository: mesos


Description (updated)
---

Added test validating hierarchical role accounting.


Diffs (updated)
-

  src/tests/api_tests.cpp dd8e221d8fd1b2a241505345337897e4ee4a6347 
  src/tests/role_tests.cpp a609ed27ef828ca82efc0d269669cda92e5f50a1 


Diff: https://reviews.apache.org/r/65940/diff/2/

Changes: https://reviews.apache.org/r/65940/diff/1-2/


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 65939: Updated role endpoints for hierarchical accounting.

[Till Toenshoff]

> On March 8, 2018, 12:20 a.m., Benjamin Mahler wrote:
> > src/master/http.cpp
> > Lines 3491 (patched)
> > 
> >
> > Just to be sure, do we disallow double slashes? E.g. "a//b"? If so, 
> > then tokenize and split provide the same functionality here, and I would be 
> > inclined to just use split to avoid having to reason about what the 
> > implications of stripping empty tokens are (e.g. it breaks the lookup 
> > logic?)

We do make sure that we got no double-slashes via 
https://github.com/apache/mesos/blob/master/src/common/roles.cpp#L71 so we 
could indeed use split here.


> On March 8, 2018, 12:20 a.m., Benjamin Mahler wrote:
> > src/master/http.cpp
> > Lines 3494-3513 (patched)
> > 
> >
> > The way this is written the root 'Node' does not contain the sum of its 
> > children's allocations, unlike all other nodes. This doesn't seem like an 
> > issue since the API does not allow you to query for the root allocation. 
> > However, might as well make the root 'Node.resources' contain the right 
> > information.

We could do this - so far I hesitated fearing that this duplicates the amount 
of invocations on our resource arithmetics. Let's discuss value vs. price.


> On March 8, 2018, 12:20 a.m., Benjamin Mahler wrote:
> > src/master/http.cpp
> > Lines 3702-3710 (patched)
> > 
> >
> > Rather than having to do this in the http code, can we have the Role 
> > struct directly expose the aggregated information as well? I'd also like 
> > the Role struct to have quota information, but that's for another patch :)

That is what my updated RR now proposes.


- Till


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


On April 5, 2018, 4:15 p.m., Till Toenshoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65939/
> ---
> 
> (Updated April 5, 2018, 4:15 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, Kapil Arya, 
> Michael Park, and Meng Zhu.
> 
> 
> Bugs: MESOS-8069
> https://issues.apache.org/jira/browse/MESOS-8069
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> When listing role "a", resources allocated to role "a/b" are added to
> those allocated to role "a". These changes affect both, the "/roles"
> endpoint as well as the V1 HTTP Call "GET_ROLES".
> Adds dynamic hierarchical role tracking to the master.
> 
> 
> Diffs
> -
> 
>   include/mesos/mesos.proto 676f0b090cad7ebf59eb32556f17ff8b5f247907 
>   include/mesos/v1/master/master.proto 
> ddb28f96b2a3a439bb9a829995a9a3015f65ba43 
>   include/mesos/v1/mesos.proto 10d506517c9f098374ab0c8f4dcfda42e1896c95 
>   src/master/http.cpp 34c9023906eca94965acc994f20e888c1f47b962 
>   src/master/master.hpp 0d9620dd0c232dc1df83477e838eeb7313bf8828 
>   src/master/master.cpp 18382fa93fd0c59e641e00f2028ac1ae2e67c01c 
>   src/master/quota_handler.cpp 21bafd0064e9397f88185eaf687a58f85da94e2c 
>   src/master/weights_handler.cpp 1053652804a8fc6af31a3b8a9f632f836c897fa9 
>   src/tests/api_tests.cpp dd8e221d8fd1b2a241505345337897e4ee4a6347 
>   src/tests/role_tests.cpp a609ed27ef828ca82efc0d269669cda92e5f50a1 
> 
> 
> Diff: https://reviews.apache.org/r/65939/diff/2/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Re: Review Request 66347: Added a test for killing executor during task launch.

[Meng Zhu]

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

(Updated April 5, 2018, 9:08 a.m.)


Review request for mesos and Greg Mann.


Changes
---

Made an call expectation more precise


Bugs: MESOS-8617 and MESOS-8624
https://issues.apache.org/jira/browse/MESOS-8617
https://issues.apache.org/jira/browse/MESOS-8624


Repository: mesos


Description
---

This test verifies that when agent shuts down a running
executor, launching tasks on the agent that use the same
executor will be dropped properly.


Diffs (updated)
-

  src/tests/slave_tests.cpp 0d7d9726ee39e4c588ea5eb8a54a73fbe1249353 


Diff: https://reviews.apache.org/r/66347/diff/4/

Changes: https://reviews.apache.org/r/66347/diff/3-4/


Testing
---

make check


Thanks,

Meng Zhu

Re: Review Request 66476: Tightened resource provider manager registrar tests.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66476']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66476

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66476/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (113 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1078 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (35 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (38 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (77 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (817 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (845 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (817 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (844 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (450888 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66476/logs/mesos-tests-stderr.log):

```
I0405 15:23:55.351030 16460 slave.cpp:3877] Shutting down framework 
f1432ba7-03c7-4I0405 15:23:55.172027 12168 exec.cpp:162] Version: 1.6.0
I0405 15:23:55.198027 16364 exec.cpp:236] Executor registered on agent 
f1432ba7-03c7-4d28-82b1-7934de858cda-S0
I0405 15:23:55.202061 11060 executor.cpp:176] Received SUBSCRIBED event
I0405 15:23:55.207022 11060 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0405 15:23:55.208024 11060 executor.cpp:176] Received LAUNCH event
I0405 15:23:55.214015 11060 executor.cpp:648] Starting task 
13a1cb3a-1f23-4cbb-bc03-8e3cc8c5f5ed
I0405 15:23:55.296026 11060 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0405 15:23:55.324012 11060 executor.cpp:661] Forked command at 12860
I0405 15:23:55.353013  2016 exec.cpp:445] Executor asked to shutdown
I0405 15:23:55.354010  7588 executor.cpp:176] Received SHUTDOWN event
I0405 15:23:55.354010  7588 executor.cpp:758] Shutting down
I0405 15:23:55.354010  7588 executor.cpp:868] Sending SIGTERM to process tree 
at pid d28-82b1-7934de858cda-
I0405 15:23:55.351030 15828 master.cpp:10449] Updating the state of task 
13a1cb3a-1f23-4cbb-bc03-8e3cc8c5f5ed of framework 
f1432ba7-03c7-4d28-82b1-7934de858cda- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0405 15:23:55.352011 16460 slave.cpp:6574] Shutting down executor 
'13a1cb3a-1f23-4cbb-bc03-8e3cc8c5f5ed' of framework 
f1432ba7-03c7-4d28-82b1-7934de858cda- at executor(1)@10.3.1.8:57221
I0405 15:23:55.353013 16460 slave.cpp:923] Agent terminating
W0405 15:23:55.353013 16460 slave.cpp:3873] Ignoring shutdown framework 
f1432ba7-03c7-4d28-82b1-7934de858cda- because it is terminating
I0405 15:23:55.355010 15828 master.cpp:10548] Removing task 
13a1cb3a-1f23-4cbb-bc03-8e3cc8c5f5ed with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework f1432ba7-03c7-4d28-82b1-7934de858cda- on 
agent f1432ba7-03c7-4d28-82b1-7934de858cda-S0 at slave(418)@10.3.1.8:57200 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 15:23:55.356009 10220 containerizer.cpp:2338] Destroying container 
19d9b4d6-ae5f-486d-888f-187524ed071a in RUNNING state
I0405 15:23:55.356009 10220 containerizer.cpp:2952] Transitioning the state of 
container 19d9b4d6-ae5f-486d-888f-187524ed071a from RUNNING to DESTROYING
I0405 15:23:55.357038 10220 launcher.cpp:156] Asked to destroy container 
19d9b4d6-ae5f-486d-888f-187524ed071a
I0405 15:23:55.358007 15828 master.cpp:1295] Agent 
f1432ba7-03c7-4d28-82b1-7934de858cda-S0 at slave(418)@10.3.1.8:57200 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0405 15:23:55.358007 15828 master.cpp:3286] Disconnecting agent 

Re: Review Request 66474: Updated minimum supported Linux kernel version.

[Mesos Reviewbot Windows]

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



PASS: Mesos patch 66474 was successfully built and tested.

Reviews applied: `['66404', '66474']`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66474

- Mesos Reviewbot Windows


On April 5, 2018, 5:51 p.m., Andrei Budnik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66474/
> ---
> 
> (Updated April 5, 2018, 5:51 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Benjamin Bannier, Gilbert 
> Song, and Jie Yu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Implementation of `freezer` cgroup, which supports nested containers,
> was introduced in 2.6.28. This patch updates documentation.
> 
> 
> Diffs
> -
> 
>   docs/building.md 909d3ca265ff176cfc5201bd552e2e0fdb378b28 
> 
> 
> Diff: https://reviews.apache.org/r/66474/diff/1/
> 
> 
> Testing
> ---
> 
> None: not a functional change.
> 
> 
> Thanks,
> 
> Andrei Budnik
> 
>

Re: Review Request 66474: Updated minimum supported Linux kernel version.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66404, 66474]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 5, 2018, 12:21 p.m., Andrei Budnik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66474/
> ---
> 
> (Updated April 5, 2018, 12:21 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Benjamin Bannier, Gilbert 
> Song, and Jie Yu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Implementation of `freezer` cgroup, which supports nested containers,
> was introduced in 2.6.28. This patch updates documentation.
> 
> 
> Diffs
> -
> 
>   docs/building.md 909d3ca265ff176cfc5201bd552e2e0fdb378b28 
> 
> 
> Diff: https://reviews.apache.org/r/66474/diff/1/
> 
> 
> Testing
> ---
> 
> None: not a functional change.
> 
> 
> Thanks,
> 
> Andrei Budnik
> 
>

Review Request 66476: Tightened resource provider manager registrar tests.

[Benjamin Bannier]

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

Review request for mesos, Chun-Hung Hsiao and Jan Schlicht.


Repository: mesos


Description
---

This patch changes tests of operations on the resource provider
manager registrar to make the operations return with a success instead
of just checking that the future results get ready.


Diffs
-

  src/tests/resource_provider_manager_tests.cpp 
05ae5defb986103520cf630d5578e8a04e662313 


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


Testing
---

`make check`


Thanks,

Benjamin Bannier

Re: Review Request 66404: Removed check for nested cgroup support in `cgroups::prepare()`.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66404']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66404

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66404/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (108 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1079 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (37 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (39 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (77 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (786 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (811 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (848 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (874 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (445682 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66404/logs/mesos-tests-stderr.log):

```
I0405 13:14:05.483306  7352 hierarchical.cpp:405] Deactivated framework 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5-
I0405 13:14:05.484505  6584 slave.cpp:3877] Shutting down framework 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5-
I0405 13:14:05.484505  6584 slave.cpp:6574] Shutting down executor 
'eea80d2a-f6e6-487d-863c-848577cde28d' of framework 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5- at executor(1)@10.3.1.8:52503
I0405 13:14:05.485291  6584 slave.cpp:923] Agent terminating
W0405 13:14:05.486330  6584 slave.cpp:3873] Ignoring shutdown framework 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5- because it is terminating
I0405 13:14:05.487377 15824 master.cpp:10548] Removing task 
eea80d2a-f6e6-487d-863c-848577cde28d with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework 0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5- on 
agent 0c3a33ec-2I0405 13:14:05.285285  7260 exec.cpp:162] Version: 1.6.0
I0405 13:14:05.312283 15564 exec.cpp:236] Executor registered on agent 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5-S0
I0405 13:14:05.316283 15092 executor.cpp:176] Received SUBSCRIBED event
I0405 13:14:05.322288 15092 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0405 13:14:05.322288 15092 executor.cpp:176] Received LAUNCH event
I0405 13:14:05.328284 15092 executor.cpp:648] Starting task 
eea80d2a-f6e6-487d-863c-848577cde28d
I0405 13:14:05.410300 15092 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0405 13:14:05.452358 15092 executor.cpp:661] Forked command at 2320
I0405 13:14:05.486330  7304 exec.cpp:445] Executor asked to shutdown
I0405 13:14:05.487377 15260 executor.cpp:176] Received SHUTDOWN event
I0405 13:14:05.487377 15260 executor.cpp:758] Shutting down
I0405 13:14:05.487377 15260 executor.cpp:868] Sending SIGTERM to process tree 
at pid 2edf-4a7c-9a01-fa211fca1ff5-S0 at slave(418)@10.3.1.8:52482 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 13:14:05.490291  6584 containerizer.cpp:2338] Destroying container 
9e60e77a-2de4-473c-8fab-63890979662e in RUNNING state
I0405 13:14:05.490291  6584 containerizer.cpp:2952] Transitioning the state of 
container 9e60e77a-2de4-473c-8fab-63890979662e from RUNNING to DESTROYING
I0405 13:14:05.491295 15824 master.cpp:1295] Agent 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5-S0 at slave(418)@10.3.1.8:52482 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0405 13:14:05.491295  6584 launcher.cpp:156] Asked to destroy container 
9e60e77a-2de4-473c-8fab-63890979662e
I0405 13:14:05.491295 15824 master.cpp:3286] Disconnecting agent 
0c3a33ec-2edf-4a7c-9a01-fa211fca1ff5-S0 at slave(418)@10.3.1.8:52482 

Review Request 66474: Updated minimum supported Linux kernel version.

[Andrei Budnik]

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

Review request for mesos, Alexander Rukletsov, Benjamin Bannier, Gilbert Song, 
and Jie Yu.


Repository: mesos


Description
---

Implementation of `freezer` cgroup, which supports nested containers,
was introduced in 2.6.28. This patch updates documentation.


Diffs
-

  docs/building.md 909d3ca265ff176cfc5201bd552e2e0fdb378b28 


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


Testing
---

None: not a functional change.


Thanks,

Andrei Budnik

Re: Review Request 66471: Added stringification for resource provider message type.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66471]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 5, 2018, 8:48 a.m., Benjamin Bannier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66471/
> ---
> 
> (Updated April 5, 2018, 8:48 a.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Jan Schlicht.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added stringification for resource provider message type.
> 
> 
> Diffs
> -
> 
>   src/resource_provider/message.hpp ae752fcc039e901f87dd130f7819657903e6d08d 
> 
> 
> Diff: https://reviews.apache.org/r/66471/diff/1/
> 
> 
> Testing
> ---
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Re: Review Request 65462: Used the new 'route()' overload from libprocess.

[Benno Evers]

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

(Updated April 5, 2018, 10:28 a.m.)


Review request for mesos, Alexander Rukletsov and Benjamin Mahler.


Summary (updated)
-

Used the new 'route()' overload from libprocess.


Repository: mesos


Description
---

Use the new 'route()' overload from libprocess.


Diffs
-

  src/files/files.cpp c392019cde193125ecb532f222dd287b7a91abad 
  src/master/registrar.cpp a83514294010139117d983800d2819d65e8c2d9e 


Diff: https://reviews.apache.org/r/65462/diff/2/


Testing
---


Thanks,

Benno Evers

Re: Review Request 66454: Updated the documented release schedule.

[Alexander Rukletsov]

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


Ship it!




Ship It!

- Alexander Rukletsov


On April 4, 2018, 6:48 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66454/
> ---
> 
> (Updated April 4, 2018, 6:48 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Jie Yu, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Updated the documented release schedule.
> 
> 
> Diffs
> -
> 
>   docs/versioning.md 70feb53d68e579a4ec7dd545648caa898cbbf6de 
> 
> 
> Diff: https://reviews.apache.org/r/66454/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 66471: Added stringification for resource provider message type.

[Mesos Reviewbot Windows]

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



FAIL: Some of the unit tests failed. Please check the relevant logs.

Reviews applied: `['66471']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66471

Relevant logs:

- 
[mesos-tests-stdout.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66471/logs/mesos-tests-stdout.log):

```
[   OK ] Endpoint/SlaveEndpointTest.NoAuthorizer/2 (115 ms)
[--] 9 tests from Endpoint/SlaveEndpointTest (1098 ms total)

[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/0 (45 
ms)
[ RUN  ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1
[   OK ] ContainerizerType/DefaultContainerDNSFlagTest.ValidateFlag/1 (50 
ms)
[--] 2 tests from ContainerizerType/DefaultContainerDNSFlagTest (97 ms 
total)

[--] 1 test from IsolationFlag/CpuIsolatorTest
[ RUN  ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0
[   OK ] IsolationFlag/CpuIsolatorTest.ROOT_UserCpuUsage/0 (744 ms)
[--] 1 test from IsolationFlag/CpuIsolatorTest (769 ms total)

[--] 1 test from IsolationFlag/MemoryIsolatorTest
[ RUN  ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0
[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (841 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (868 ms total)

[--] Global test environment tear-down
[==] 949 tests from 94 test cases ran. (450660 ms total)
[  PASSED  ] 948 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] CommandExecutorCheckTest.CommandCheckTimeout

 1 FAILED TEST
  YOU HAVE 214 DISABLED TESTS

```

- 
[mesos-tests-stderr.log](http://dcos-win.westus.cloudapp.azure.com/mesos-build/review/66471/logs/mesos-tests-stderr.log):

```
I0405 09:43:56.038856 15188 master.cpp:10449] Updating the state of task 
c27652d7-8d0e-45bd-93f4-a1528e05f8a2 of framework 
fa998259-f91d-44fe-b4d7-af382bf4aac6- (latest state: TASK_KILLED, status 
update state: TASK_KILLED)
I0405 09:43:56.038856 11060 slave.cpp:3877] Shutting down framework 
fa998259-f91d-44fe-b4d7-af382bf4aac6-
I0405 09:43:56.038856 11060 slave.cpp:6574] Shutting down executor 
'c27652d7-8d0e-45bd-93f4-a1528e05f8a2' of framework 
fa998259-f91d-44fe-b4d7-af382bf4aac6- at executor(1)@10.3.1.8:64524
I0405 09:43:56.038856  8012 slave.cpp:923] Agent terminating
W0405 09:43:56.038856  8012 slave.cpp:3873] Ignoring shutdown I0405 
09:43:55.850879  5704 exec.cpp:162] Version: 1.6.0
I0405 09:43:55.876843 15176 exec.cpp:236] Executor registered on agent 
fa998259-f91d-44fe-b4d7-af382bf4aac6-S0
I0405 09:43:55.880893  6056 executor.cpp:176] Received SUBSCRIBED event
I0405 09:43:55.885879  6056 executor.cpp:180] Subscribed executor on 
winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net
I0405 09:43:55.885879  6056 executor.cpp:176] Received LAUNCH event
I0405 09:43:55.891913  6056 executor.cpp:648] Starting task 
c27652d7-8d0e-45bd-93f4-a1528e05f8a2
I0405 09:43:55.977883  6056 executor.cpp:483] Running 
'D:\DCOS\mesos\src\mesos-containerizer.exe launch '
I0405 09:43:56.009865  6056 executor.cpp:661] Forked command at 15152
I0405 09:43:56.038856 14824 exec.cpp:445] Executor asked to shutdown
I0405 09:43:56.038856  6336 executor.cpp:176] Received SHUTDOWN event
I0405 09:43:56.038856  6336 executor.cpp:758] Shutting down
I0405 09:43:56.038856  6336 executor.cpp:868] Sending SIGTERM to process tree 
at pid framework fa998259-f91d-44fe-b4d7-af382bf4aac6- because it is 
terminating
I0405 09:43:56.038856 15188 master.cpp:10548] Removing task 
c27652d7-8d0e-45bd-93f4-a1528e05f8a2 with resources cpus(allocated: *):4; 
mem(allocated: *):2048; disk(allocated: *):1024; ports(allocated: 
*):[31000-32000] of framework fa998259-f91d-44fe-b4d7-af382bf4aac6- on 
agent fa998259-f91d-44fe-b4d7-af382bf4aac6-S0 at slave(418)@10.3.1.8:64503 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 09:43:56.043845 15188 master.cpp:1295] Agent 
fa998259-f91d-44fe-b4d7-af382bf4aac6-S0 at slave(418)@10.3.1.8:64503 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net) disconnected
I0405 09:43:56.043845 15188 master.cpp:3286] Disconnecting agent 
fa998259-f91d-44fe-b4d7-af382bf4aac6-S0 at slave(418)@10.3.1.8:64503 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 09:43:56.043845 15188 master.cpp:3305] Deactivating agent 
fa998259-f91d-44fe-b4d7-af382bf4aac6-S0 at slave(418)@10.3.1.8:64503 
(winbldsrv-01.zq4gs31qjdiunm1ryi1452nvnh.dx.internal.cloudapp.net)
I0405 09:43:56.043845 10576 hierarchical.cpp:344] Removed 

Review Request 66471: Added stringification for resource provider message type.

[Benjamin Bannier]

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

Review request for mesos, Chun-Hung Hsiao and Jan Schlicht.


Repository: mesos


Description
---

Added stringification for resource provider message type.


Diffs
-

  src/resource_provider/message.hpp ae752fcc039e901f87dd130f7819657903e6d08d 


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


Testing
---

`make check`


Thanks,

Benjamin Bannier

Re: Review Request 66454: Updated the documented release schedule.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [66454]

Passed command: export OS='ubuntu:14.04' BUILDTOOL='autotools' COMPILER='gcc' 
CONFIGURATION='--verbose --disable-libtool-wrappers' ENVIRONMENT='GLOG_v=1 
MESOS_VERBOSE=1'; ./support/docker-build.sh

- Mesos Reviewbot


On April 4, 2018, 6:48 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/66454/
> ---
> 
> (Updated April 4, 2018, 6:48 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Jie Yu, and Vinod Kone.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Updated the documented release schedule.
> 
> 
> Diffs
> -
> 
>   docs/versioning.md 70feb53d68e579a4ec7dd545648caa898cbbf6de 
> 
> 
> Diff: https://reviews.apache.org/r/66454/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Greg Mann
> 
>