Re: Review Request 70133: Removed unnecessary accept filters in SLRP tests.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [70132, 70537, 70521, 70133]

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

- Mesos Reviewbot


On April 9, 2019, 9:21 p.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70133/
> ---
> 
> (Updated April 9, 2019, 9:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier and Meng Zhu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removed unnecessary accept filters in SLRP tests.
> 
> 
> Diffs
> -
> 
>   src/tests/storage_local_resource_provider_tests.cpp 
> bd35150200a23ba57408f5d64a975f8a2f062018 
> 
> 
> Diff: https://reviews.apache.org/r/70133/diff/2/
> 
> 
> Testing
> ---
> 
> `sudo make check`
> 
> Especially, tested that each of the three modified tests finishes in 5 
> seconds.
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70518', '70519']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3251/mesos-review-70519

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3251/mesos-review-70519/logs/mesos-tests.log):

```
I0424 04:51:40.370427 74936 master.cpp:3312] Disconnecting agent 
06c23f02-e3eb-4dd8-ab79-a3df5d520129-S0 at slave(504)@192.10.1.4:63349 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0424 04:51:40.371417 74936 master.cpp:3331] Deactivating agent 
06c23f02-e3eb-4dd8-ab79-a3df5d520129-S0 at slave(504)@192.10.1.4:63349 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0424 04:51:40.371417 73644 hierarchical.cpp:392] Removed framework 
06c23f02-e3eb-4dd8-ab79-a3df5d520129-
I0424 04:51:40.372419 73644 hierarchical.cpp:829] Agent 
06c23f02-e3eb-4dd8-ab79-a3df5d520129-S0 deactivated
I0424 04:51:40.373417 74440 containerizer.cpp:2576] Destroying container 
f80bc0d4-188f-4414-8e0e-a4665ace0336 in RUNNING state
I0424 04:51:40.373417 74440 containerizer.cpp:3278] Transitioning the state of 
container f80bc0d4-188f-4414-8e0e-a4665ace0336 from RUNNING to DESTROYING
I0424 04:51:40.374425 74440 launcher.cpp:161] Asked to destroy container 
f80bc0d4-188f-4414-8e0e-a4665ace0336
W0424 04:51:40.375447 74592 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=8556 to peer '192.10.1.4:49373': IO failed with error 
code: The specified network name is no longer available.

W0424 04:51:40.376427 74592 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=10204 to peer '192.10.1.4:49374': IO failed with error 
code: The specified network name is no longer available.

I0424 04:51:40.398418 73644 containerizer.cpp:3117] Container 
f80bc0d4-188f-4414-8e0e-a4665ace0336 has exited
I0424 04:51:40.436426 71952 master.cpp:1135] Master terminating
I0424 04:51:40.438437 71884 hierarchical.cpp:680][   OK ] 
IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (879 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (898 ms total)

[--] Global test environment tear-down
[==] 1166 tests from 109 test cases ran. (588351 ms total)
[  PASSED  ] 1163 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

 Removed agent 06c23f02-e3eb-4dd8-ab79-a3df5d520129-S0
I0424 04:51:42.185465 74592 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 24, 2019, 12:52 a.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70519/
> ---
> 
> (Updated April 24, 2019, 12:52 a.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch updates the master code responsible for marking
> agents as gone to properly transition tasks on agents which
> were previously marked as unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
>   src/master/master.hpp e8f77d5b107a43945124a9ea00d07562a5a09450 
>   src/master/master.cpp 73a88a2720be3900e6c6575d9ac535ceec52dc12 
>   src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 
> 
> 
> Diff: https://reviews.apache.org/r/70519/diff/3/
> 
> 
> Testing
> ---
> 
> `make check`
> `bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
> --gtest_repeat=-1 --gtest_break_on_failure`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70508: Fixed the flaky ExamplesTest.DynamicReservationFramework.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70132', '70508']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3249/mesos-review-70508

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3249/mesos-review-70508/logs/mesos-tests.log):

```
I0424 03:38:21.542529 76672 master.cpp:3312] Disconnecting agent 
068e9bd3-f8ea-42f4-9d40-5990ce26807e-S0 at slave(502)@192.10.1.4:60668 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0424 03:38:21.543520 77260 hierarchical.cpp:392] Removed framework 
068e9bd3-f8ea-42f4-9d40-5990ce26807e-
I0424 03:38:21.543520 76672 master.cpp:3331] Deactivating agent 
068e9bd3-f8ea-42f4-9d40-5990ce26807e-S0 at slave(502)@192.10.1.4:60668 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0424 03:38:21.543520 77260 hierarchical.cpp:829] Agent 
068e9bd3-f8ea-42f4-9d40-5990ce26807e-S0 deactivated
I0424 03:38:21.545583 76112 containerizer.cpp:2576] Destroying container 
8cc5140d-8a8d-410e-b9e1-d5d6fc0a5b21 in RUNNING state
I0424 03:38:21.545583 76112 containerizer.cpp:3278] Transitioning the state of 
container 8cc5140d-8a8d-410e-b9e1-d5d6fc0a5b21 from RUNNING to DESTROYING
I0424 03:38:21.546515 76112 launcher.cpp:161] Asked to destroy container 
8cc5140d-8a8d-410e-b9e1-d5d6fc0a5b21
W0424 03:38:21.547516 74940 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=11360 to peer '192.10.1.4:63080': IO failed with error 
code: The specified network name is no longer available.

W0424 03:38:21.547516 74940 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=11744 to peer '192.10.1.4:63081': IO failed with error 
code: The speci[   OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 
(785 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (803 ms total)

[--] Global test environment tear-down
[==] 1164 tests from 109 test cases ran. (587040 ms total)
[  PASSED  ] 1161 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

fied network name is no longer available.

I0424 03:38:21.599570 76992 containerizer.cpp:3117] Container 
8cc5140d-8a8d-410e-b9e1-d5d6fc0a5b21 has exited
I0424 03:38:21.630559 73944 master.cpp:1135] Master terminating
I0424 03:38:21.632529 76672 hierarchical.cpp:680] Removed agent 
068e9bd3-f8ea-42f4-9d40-5990ce26807e-S0
I0424 03:38:22.724555 74940 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 22, 2019, 4:47 p.m., Benjamin Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70508/
> ---
> 
> (Updated April 22, 2019, 4:47 p.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Meng Zhu.
> 
> 
> Bugs: MESOS-5804
> https://issues.apache.org/jira/browse/MESOS-5804
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The test failed in MESOS-5804 due to the following race:
> 
>   1. Framework launches task T, moves from RESERVED to
>  TASK_RUNNING state.
>   2. Allocation cycle triggers and will send the unreserved
>  resources to the framework.
>   3. Before the offer gets to the framework, task T finishes and
>  framework moves from TASK_RUNNING to RESERVED.
>   4. In the RESERVED state, the framework expects the reservation
>  in the offer. But, it's coming in a later offer, and the one
>  that arrives is for the unreserved resources since it was
>  generated while the task was still running.
> 
> Tne fix applied here for this specific race is to use a 2 week
> filter rather than a 0 second filter. That would ensure that the
> unreserved resources do not get re-offered to the framework on
> their own. However, this fix does not work until MESOS-9616 is
> resolved.
> 
> 
> Diffs
> -
> 
>   src/examples/dynamic_reservation_framework.cpp 
> f9c7dfe46a1e8dd1bc8eae45ed1b65b7a6d60dfc 
> 
> 
> Diff: https://reviews.apache.org/r/70508/diff/1/
> 
> 
> Testing
> ---
> 
> Test passes with https://reviews.apache.org/r/70132/ applied.
> 
> 
> Thanks,
> 
> Benjamin Mahler
> 
>

Review Request 70538: WIP: Fixed upgrade path for tasks with invalid protobuf unions.

[Joseph Wu]

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

Review request for mesos, Andrei Sekretenko, Benno Evers, and Greg Mann.


Repository: mesos


Description
---

As part of MESOS-6874, the master now validates protobuf unions
passed as part of an ExecutorInfo::ContainerInfo.  This prevents a
task from specifying, for example, a ContainerInfo::MESOS, but filling
out the `docker` field (which is then ignored by the agent).

However, if a task was already launched with an invalid protobuf
union, the same validation will happen when the agent tries to
reregister with the master.  In this case, if the master is upgraded
to validate protobuf unions, the agent reregistration will be rejected.

This adds a hack to wipe invalid fields from the agent's reregistration
message before sending it to the master.


Diffs
-

  src/slave/slave.cpp 95f05a18c7905d5032de1cd35726ac3a17f0b682 


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


Testing
---

WIP!!!


Thanks,

Joseph Wu

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [70518, 70519]

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

- Mesos Reviewbot


On April 24, 2019, 12:52 a.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70519/
> ---
> 
> (Updated April 24, 2019, 12:52 a.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch updates the master code responsible for marking
> agents as gone to properly transition tasks on agents which
> were previously marked as unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
>   src/master/master.hpp e8f77d5b107a43945124a9ea00d07562a5a09450 
>   src/master/master.cpp 73a88a2720be3900e6c6575d9ac535ceec52dc12 
>   src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 
> 
> 
> Diff: https://reviews.apache.org/r/70519/diff/3/
> 
> 
> Testing
> ---
> 
> `make check`
> `bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
> --gtest_repeat=-1 --gtest_break_on_failure`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Greg Mann]

> On April 23, 2019, 4:57 p.m., Benno Evers wrote:
> > src/master/master.cpp
> > Lines 9230 (patched)
> > 
> >
> > Nit: I'd probably write this as
> > 
> > CHECK(slaves.recovered.contains(slaveId) || 
> > slaves.unreachable.contains(slaveId))
> > 
> > That way the code matches exactly what's written in the comment.

Done.


> On April 23, 2019, 4:57 p.m., Benno Evers wrote:
> > src/master/master.cpp
> > Lines 9243 (patched)
> > 
> >
> > Nit: We could save one level of indentation (and more importantly one 
> > item on the reader's mental stack) by writing this as
> > 
> > if (framework == nullptr) {
> >   continue;
> > }

Done.


- Greg


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


On April 24, 2019, 12:52 a.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70519/
> ---
> 
> (Updated April 24, 2019, 12:52 a.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch updates the master code responsible for marking
> agents as gone to properly transition tasks on agents which
> were previously marked as unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
>   src/master/master.hpp e8f77d5b107a43945124a9ea00d07562a5a09450 
>   src/master/master.cpp 73a88a2720be3900e6c6575d9ac535ceec52dc12 
>   src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 
> 
> 
> Diff: https://reviews.apache.org/r/70519/diff/3/
> 
> 
> Testing
> ---
> 
> `make check`
> `bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
> --gtest_repeat=-1 --gtest_break_on_failure`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70535: Extended 'ResourceQuantities' to facilitate a bug fix.

[Mesos Reviewbot Windows]

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



FAIL: Failed to apply the current review.

Failed command: `python.exe .\support\apply-reviews.py -n -r 70535`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3248/mesos-review-70535

Relevant logs:

- 
[apply-review-70535.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3248/mesos-review-70535/logs/apply-review-70535.log):

```
error: patch failed: src/common/resource_quantities.hpp:110
error: src/common/resource_quantities.hpp: patch does not apply
```

- Mesos Reviewbot Windows


On April 23, 2019, 11:21 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70535/
> ---
> 
> (Updated April 23, 2019, 11:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9619
> https://issues.apache.org/jira/browse/MESOS-9619
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch makes minimal updates to the `ResourceQuantities`
> class in order to facilitate the fix for MESOS-9619.
> 
> The original review which added the methods included in this
> patch can be found at https://reviews.apache.org/r/70062/.
> 
> 
> Diffs
> -
> 
>   src/common/resource_quantities.hpp 11eb426104577b7977c2307df3e4917085cd 
>   src/common/resource_quantities.cpp 320983929cd7d14973c4b98d6ed5338de690ff5f 
> 
> 
> Diff: https://reviews.apache.org/r/70535/diff/1/
> 
> 
> Testing
> ---
> 
> `make check` after the patches associated with MESOS-9619 had been 
> cherry-picked onto the '1.7.x' branch.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70521: Renamed variables in `Master::_accept` to improve readability.

[Chun-Hung Hsiao]

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

(Updated April 24, 2019, 2:04 a.m.)


Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.


Changes
---

Rebased.


Repository: mesos


Description
---

Renamed variables in `Master::_accept` to improve readability.


Diffs (updated)
-

  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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

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


Testing
---

make check


Thanks,

Chun-Hung Hsiao

Review Request 70537: Added unit tests for implicit decline.

[Chun-Hung Hsiao]

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

Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.


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


Repository: mesos


Description
---

Added unit tests for implicit decline.


Diffs
-

  src/tests/scheduler_tests.cpp e0ed02900330c678bbf5c609c1f45d05147851ed 


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


Testing
---

make check

Tests `ImplicitDecline3` and `ImplicitDecline5` will fail w/o r/70132.


Thanks,

Chun-Hung Hsiao

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Chun-Hung Hsiao]

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

(Updated April 24, 2019, 2:02 a.m.)


Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.


Changes
---

Addressed some of Benjamin's comments and added examples.


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


Repository: mesos


Description
---

Currently if a framework accepts an offer to perform pipelined
operations, e.g., reserving resource, without a final consumer, the
converted resources will be implicitly declined. This is an undesired
behavior as the framework might want to reserve one resource first but
launch a task later in the next allocation cycle. This patch fixes this
behavior.

But, if the framework accepts an offers with multiple operations that
cancel out each other, the resources consumed by these operations are
still considered unused and will be declined.


Diffs (updated)
-

  docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
  src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 


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

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


Testing (updated)
---

make check

More testing done in r/70537.


Thanks,

Chun-Hung Hsiao

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Chun-Hung Hsiao]

> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > src/tests/slave_tests.cpp
> > Lines 6499 (patched)
> > 
> >
> > Since the changes in this patch are strongly related to behavior 
> > framework authors need to reason about I strongly feel that we must add a 
> > test for the expected behavior.
> 
> Chun-Hung Hsiao wrote:
> I could add a unit test in a separated patch. This patch itself will be 
> backported, after discussed with @bmahler.

Done in r/70537.


- Chun-Hung


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


On April 23, 2019, 1:15 a.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> ---
> 
> (Updated April 23, 2019, 1:15 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
> https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly declined. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be declined.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Greg Mann]

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

(Updated April 24, 2019, 12:52 a.m.)


Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
Kone.


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


Repository: mesos


Description
---

This patch updates the master code responsible for marking
agents as gone to properly transition tasks on agents which
were previously marked as unreachable.


Diffs (updated)
-

  src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
  src/master/master.hpp e8f77d5b107a43945124a9ea00d07562a5a09450 
  src/master/master.cpp 73a88a2720be3900e6c6575d9ac535ceec52dc12 
  src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 


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

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


Testing
---

`make check`
`bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
--gtest_repeat=-1 --gtest_break_on_failure`


Thanks,

Greg Mann

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Greg Mann]

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

(Updated April 24, 2019, 12:46 a.m.)


Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
Kone.


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


Repository: mesos


Description
---

This patch updates the master code responsible for marking
agents as gone to properly transition tasks on agents which
were previously marked as unreachable.


Diffs (updated)
-

  src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
  src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
  src/master/master.hpp e8f77d5b107a43945124a9ea00d07562a5a09450 
  src/master/master.cpp 73a88a2720be3900e6c6575d9ac535ceec52dc12 
  src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 


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

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


Testing
---

`make check`
`bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
--gtest_repeat=-1 --gtest_break_on_failure`


Thanks,

Greg Mann

Re: Review Request 70535: Extended 'ResourceQuantities' to facilitate a bug fix.

[Meng Zhu]

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


Ship it!




Ship It!

- Meng Zhu


On April 23, 2019, 4:21 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70535/
> ---
> 
> (Updated April 23, 2019, 4:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9619
> https://issues.apache.org/jira/browse/MESOS-9619
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch makes minimal updates to the `ResourceQuantities`
> class in order to facilitate the fix for MESOS-9619.
> 
> The original review which added the methods included in this
> patch can be found at https://reviews.apache.org/r/70062/.
> 
> 
> Diffs
> -
> 
>   src/common/resource_quantities.hpp 11eb426104577b7977c2307df3e4917085cd 
>   src/common/resource_quantities.cpp 320983929cd7d14973c4b98d6ed5338de690ff5f 
> 
> 
> Diff: https://reviews.apache.org/r/70535/diff/1/
> 
> 
> Testing
> ---
> 
> `make check` after the patches associated with MESOS-9619 had been 
> cherry-picked onto the '1.7.x' branch.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70535: Extended 'ResourceQuantities' to facilitate a bug fix.

[Mesos Reviewbot]

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



Bad review!

Reviews applied: [70535]

Error:
2019-04-23 23:44:41 URL:https://reviews.apache.org/r/70535/diff/raw/ 
[3439/3439] -> "70535.patch" [1]
error: patch failed: src/common/resource_quantities.hpp:110
error: src/common/resource_quantities.hpp: patch does not apply

- Mesos Reviewbot


On April 23, 2019, 11:21 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70535/
> ---
> 
> (Updated April 23, 2019, 11:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9619
> https://issues.apache.org/jira/browse/MESOS-9619
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch makes minimal updates to the `ResourceQuantities`
> class in order to facilitate the fix for MESOS-9619.
> 
> The original review which added the methods included in this
> patch can be found at https://reviews.apache.org/r/70062/.
> 
> 
> Diffs
> -
> 
>   src/common/resource_quantities.hpp 11eb426104577b7977c2307df3e4917085cd 
>   src/common/resource_quantities.cpp 320983929cd7d14973c4b98d6ed5338de690ff5f 
> 
> 
> Diff: https://reviews.apache.org/r/70535/diff/1/
> 
> 
> Testing
> ---
> 
> `make check` after the patches associated with MESOS-9619 had been 
> cherry-picked onto the '1.7.x' branch.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70515: Added a test to verify non-root nested container can access its sandbox.

[Gilbert Song]

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


Ship it!




I thought we were going to add a test to default executor test?

- Gilbert Song


On April 22, 2019, 6:27 a.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70515/
> ---
> 
> (Updated April 22, 2019, 6:27 a.m.)
> 
> 
> Review request for mesos, Andrei Budnik, Gilbert Song, and James Peach.
> 
> 
> Bugs: MESOS-9536
> https://issues.apache.org/jira/browse/MESOS-9536
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added a test to verify non-root nested container can access its sandbox.
> 
> 
> Diffs
> -
> 
>   src/tests/containerizer/nested_mesos_containerizer_tests.cpp 
> bbf83fa24966a7c9f585b9912fa77bf3460db26f 
> 
> 
> Diff: https://reviews.apache.org/r/70515/diff/1/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> This test will fail without the previous patch 
> (https://reviews.apache.org/r/70514/ ).
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 70514: Made nested contaienr can access its sandbox via `MESOS_SANDBOX`.

[Gilbert Song]

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




src/slave/containerizer/mesos/containerizer.cpp
Lines 1844 (patched)


s/has no/does not have/g

could we also mention that currently the container new mount namespace is 
not configurable, it bases on whether or not the filesystem/linux isolator is 
turned on.



src/slave/containerizer/mesos/isolators/filesystem/linux.cpp
Lines 508 (patched)


Seems like this mount point will be on the host fs forever


- Gilbert Song


On April 22, 2019, 6:25 a.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70514/
> ---
> 
> (Updated April 22, 2019, 6:25 a.m.)
> 
> 
> Review request for mesos, Andrei Budnik, Gilbert Song, and James Peach.
> 
> 
> Bugs: MESOS-9536
> https://issues.apache.org/jira/browse/MESOS-9536
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Previously in MESOS-8332 we narrowed task sandbox permissions from 0755
> to 0750 which will cause nested container may not has permission to
> access its sandbox via the environment variable `MESOS_SANDBOX`. Now in
> this patch, for nested container which has no its own rootfs, we bind
> mount its sandbox to the directory specified via the agent flag
> `--sandbox_directory` and set `MESOS_SANDBOX` to `--sandbox_directory`
> as well, in this way such nested container will have the permission
> to access its sandbox via `MESOS_SANDBOX`.
> 
> 
> Diffs
> -
> 
>   src/slave/containerizer/mesos/containerizer.cpp 
> 043244841a73fa3f5f7119bc38f6d3a04be8990b 
>   src/slave/containerizer/mesos/isolators/filesystem/linux.cpp 
> 725754f26855ea54ccf8cbcb288ee3b29e8ed4e7 
> 
> 
> Diff: https://reviews.apache.org/r/70514/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Review Request 70535: Extended 'ResourceQuantities' to facilitate a bug fix.

[Greg Mann]

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

Review request for mesos, Benjamin Mahler and Meng Zhu.


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


Repository: mesos


Description
---

This patch makes minimal updates to the `ResourceQuantities`
class in order to facilitate the fix for MESOS-9619.

The original review which added the methods included in this
patch can be found at https://reviews.apache.org/r/70062/.


Diffs
-

  src/common/resource_quantities.hpp 11eb426104577b7977c2307df3e4917085cd 
  src/common/resource_quantities.cpp 320983929cd7d14973c4b98d6ed5338de690ff5f 


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


Testing
---

`make check` after the patches associated with MESOS-9619 had been 
cherry-picked onto the '1.7.x' branch.


Thanks,

Greg Mann

Re: Review Request 70526: Rearranged 'Downloads' page and updated bintray URL.

[Greg Mann]

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


Ship it!




Ship It!

- Greg Mann


On April 23, 2019, 2:32 p.m., Benno Evers wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70526/
> ---
> 
> (Updated April 23, 2019, 2:32 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Till Toenshoff.
> 
> 
> Bugs: MESOS-9697
> https://issues.apache.org/jira/browse/MESOS-9697
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Updated the bintray link on the `Downloads` page to point
> to the `apache/mesos` account instead of the `mesos`
> account.
> 
> In addition, several minor formatting changes were done:
> 
>   * Added a space after the colon in the `Getting older
> Mesos binaries` section.
> 
>   * Moved links to the getting started guide to the top
> of the document.
> 
>   * Used a list to present the download links to the latest
> stable release.
> 
>   * Used `` instead of `` tags for the link to the
> ASF git repository.
> 
> 
> Diffs
> -
> 
>   site/source/downloads.html.erb d5a165c71378a7c268b9c2e73b60902d632463fb 
> 
> 
> Diff: https://reviews.apache.org/r/70526/diff/1/
> 
> 
> Testing
> ---
> 
> Visual inspection after using Firefox to edit the HTML: 
> https://drive.google.com/file/d/1PuLGmb3h3pj3xNXciVGWPQzGBHJqHvk5/view?usp=sharing
> 
> 
> Thanks,
> 
> Benno Evers
> 
>

Re: Review Request 70534: Added tests for UPDATE_FRAMEWORK.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70408', '70377', '70379', '70530', '70531', '70532', 
'70533', '70534']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3246/mesos-review-70534

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3246/mesos-review-70534/logs/mesos-tests.log):

```
I0423 22:30:37.016196 75760 master.cpp:3368] Disconnecting agent 
2712aadd-b7f0-422f-b8ae-a899c96bdfb0-S0 at slave(510)@192.10.1.4:57800 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 22:30:37.016196 75760 master.cpp:3387] Deactivating agent 
2712aadd-b7f0-422f-b8ae-a899c96bdfb0-S0 at slave(510)@192.10.1.4:57800 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 22:30:37.017210 75380 hierarchical.cpp:392] Removed framework 
2712aadd-b7f0-422f-b8ae-a899c96bdfb0-
I0423 22:30:37.017210 75380 hierarchical.cpp:829] Agent 
2712aadd-b7f0-422f-b8ae-a899c96bdfb0-S0 deactivated
I0423 22:30:37.018199 67380 containerizer.cpp:2576] Destroying container 
ab95a0c9-47af-4055-a364-12c2556f635a in RUNNING state
I0423 22:30:37.018199 67380 containerizer.cpp:3278] Transitioning the state of 
container ab95a0c9-47af-4055-a364-12c2556f635a from RUNNING to DESTROYING
I0423 22:30:37.019191 67380 launcher.cpp:161] Asked to destroy container 
ab95a0c9-47af-4055-a364-12c2556f635a
W0423 22:30:37.020185 74508 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=15216 to peer '192.10.1.4:60227': IO failed with error 
code: The specified n[   OK ] 
IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (784 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (802 ms total)

[--] Global test environment tear-down
[==] 1172 tests from 110 test cases ran. (581750 ms total)
[  PASSED  ] 1169 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

etwork name is no longer available.

W0423 22:30:37.021200 74508 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=15176 to peer '192.10.1.4:60228': IO failed with error 
code: The specified network name is no longer available.

I0423 22:30:37.113555 75380 containerizer.cpp:3117] Container 
ab95a0c9-47af-4055-a364-12c2556f635a has exited
I0423 22:30:37.144559 75876 master.cpp:1135] Master terminating
I0423 22:30:37.145747 75380 hierarchical.cpp:680] Removed agent 
2712aadd-b7f0-422f-b8ae-a899c96bdfb0-S0
I0423 22:30:38.125605 74508 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 23, 2019, 7:05 p.m., Andrei Sekretenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70534/
> ---
> 
> (Updated April 23, 2019, 7:05 p.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added tests for UPDATE_FRAMEWORK.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am 5f97523fbe2d80733fbdcc7706f2761f5a071f9f 
>   src/tests/CMakeLists.txt e6b1d8a097246f0921467d7f778034d6754fcff6 
>   src/tests/update_framework_tests.cpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/70534/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrei Sekretenko
> 
>

Re: Review Request 70534: Added tests for UPDATE_FRAMEWORK.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [70408, 70377, 70379, 70530, 70531, 70532, 70533, 70534]

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

- Mesos Reviewbot


On April 23, 2019, 7:05 p.m., Andrei Sekretenko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70534/
> ---
> 
> (Updated April 23, 2019, 7:05 p.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Added tests for UPDATE_FRAMEWORK.
> 
> 
> Diffs
> -
> 
>   src/Makefile.am 5f97523fbe2d80733fbdcc7706f2761f5a071f9f 
>   src/tests/CMakeLists.txt e6b1d8a097246f0921467d7f778034d6754fcff6 
>   src/tests/update_framework_tests.cpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/70534/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andrei Sekretenko
> 
>

Re: Review Request 70533: Implemented the UPDATE_FRAMEWORK call.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 7:06 p.m.)


Review request for mesos and Benjamin Mahler.


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


Repository: mesos


Description
---

Implemented UPDATE_FRAMEWORK scheduler call.

This call allows to perform the same changes in FrameworkInfo as resubscribing 
a framework.

HTTP return codes specific to this call:
200 OK on success
400 Bad request when the requested update is not valid.
403 Unathorized when the framework would not be authorized to use some entities 
(currently roles) after the requested update.
409 Conflict when the framework is removed by a concurrent call.

No "incomplete updates" occur when an update is invalid. I.e. the update either 
succeeds or fails completely.

An attempt to change framework's user/checkpointing ability is not swallowed 
silently, but is treated as an error - this is different from attempting to 
change these properties by resubscribing a framework.


Diffs
-

  src/java/jni/org_apache_mesos_v1_scheduler_V0Mesos.cpp 
35a04a3d0183697f93dadb3cbfead3ee0c2fea08 
  src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
  src/master/validation.cpp f032a781608857d0c9cfa220dd8d70f74d60f1ec 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70534: Added tests for UPDATE_FRAMEWORK.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 7:05 p.m.)


Review request for mesos and Benjamin Mahler.


Repository: mesos


Description
---

Added tests for UPDATE_FRAMEWORK.


Diffs
-

  src/Makefile.am 5f97523fbe2d80733fbdcc7706f2761f5a071f9f 
  src/tests/CMakeLists.txt e6b1d8a097246f0921467d7f778034d6754fcff6 
  src/tests/update_framework_tests.cpp PRE-CREATION 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70532: Added UpdateFramework submessage.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 7:04 p.m.)


Review request for mesos and Benjamin Mahler.


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


Repository: mesos


Description
---

Added the UpdateFramework submessage.


Diffs
-

  include/mesos/scheduler/scheduler.proto 
b6d79b1c433dce77a6ee4278b3ddf6b69868c1d8 
  include/mesos/v1/scheduler/scheduler.proto 
bddd5c449fd4b294d15430746b708731aff18f2a 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70531: Made using validateFrameworkSubscription() in UPDATE_FRAMEWORK possible.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 7:04 p.m.)


Review request for mesos and Benjamin Mahler.


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


Repository: mesos


Description
---

Made using validateFrameworkSubscription() in UPDATE_FRAMEWORK possible.


Diffs
-

  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70530: Added a method for strict validation of a FrameworkInfo update.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 7:04 p.m.)


Review request for mesos and Benjamin Mahler.


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


Repository: mesos


Description
---

Added a method for a strict validation of a FrameworkInfo update.


Diffs
-

  src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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


Testing
---


Thanks,

Andrei Sekretenko

Review Request 70534: Added tests for UPDATE_FRAMEWORK.

[Andrei Sekretenko]

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

Review request for mesos and Benjamin Mahler.


Repository: mesos


Description
---

Added tests for UPDATE_FRAMEWORK.


Diffs (updated)
-

  src/Makefile.am 5f97523fbe2d80733fbdcc7706f2761f5a071f9f 
  src/tests/CMakeLists.txt e6b1d8a097246f0921467d7f778034d6754fcff6 
  src/tests/update_framework_tests.cpp PRE-CREATION 


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


Testing
---


Thanks,

Andrei Sekretenko

Review Request 70532: Added UpdateFramework submessage.

[Andrei Sekretenko]

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

Review request for mesos and Benjamin Mahler.


Repository: mesos


Description (updated)
---

Added the UpdateFramework submessage.


Diffs (updated)
-

  include/mesos/scheduler/scheduler.proto 
b6d79b1c433dce77a6ee4278b3ddf6b69868c1d8 
  include/mesos/v1/scheduler/scheduler.proto 
bddd5c449fd4b294d15430746b708731aff18f2a 


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


Testing
---


Thanks,

Andrei Sekretenko

Review Request 70533: Implemented the UPDATE_FRAMEWORK call.

[Andrei Sekretenko]

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

Review request for mesos and Benjamin Mahler.


Summary (updated)
-

Implemented the UPDATE_FRAMEWORK call.


Repository: mesos


Description (updated)
---

Implemented UPDATE_FRAMEWORK scheduler call.

This call allows to perform the same changes in FrameworkInfo as resubscribing 
a framework.

HTTP return codes specific to this call:
200 OK on success
400 Bad request when the requested update is not valid.
403 Unathorized when the framework would not be authorized to use some entities 
(currently roles) after the requested update.
409 Conflict when the framework is removed by a concurrent call.

No "incomplete updates" occur when an update is invalid. I.e. the update either 
succeeds or fails completely.

An attempt to change framework's user/checkpointing ability is not swallowed 
silently, but is treated as an error - this is different from attempting to 
change these properties by resubscribing a framework.


Diffs (updated)
-

  src/java/jni/org_apache_mesos_v1_scheduler_V0Mesos.cpp 
35a04a3d0183697f93dadb3cbfead3ee0c2fea08 
  src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
  src/master/validation.cpp f032a781608857d0c9cfa220dd8d70f74d60f1ec 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70530: Added a method for strict validation of a FrameworkInfo update.

[Andrei Sekretenko]

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

(Updated April 23, 2019, 6:53 p.m.)


Review request for mesos and Benjamin Mahler.


Repository: mesos


Description (updated)
---

Added a method for a strict validation of a FrameworkInfo update.


Diffs
-

  src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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


Testing
---


Thanks,

Andrei Sekretenko

Review Request 70531: Made using validateFrameworkSubscription() in UPDATE_FRAMEWORK possible.

[Andrei Sekretenko]

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

Review request for mesos and Benjamin Mahler.


Repository: mesos


Description
---

Made using validateFrameworkSubscription() in UPDATE_FRAMEWORK possible.


Diffs (updated)
-

  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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


Testing
---


Thanks,

Andrei Sekretenko

Review Request 70530: Added a method for strict validation of a FrameworkInfo update.

[Andrei Sekretenko]

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

Review request for mesos and Benjamin Mahler.


Repository: mesos


Description
---

Added a method for strict validation of a FrameworkInfo update.


Diffs (updated)
-

  src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
  src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
  src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 


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


Testing
---


Thanks,

Andrei Sekretenko

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Benjamin Bannier]

> On April 23, 2019, 12:47 p.m., Benjamin Bannier wrote:
> > docs/scheduler-http-api.md
> > Line 132 (original), 132 (patched)
> > 
> >
> > What do you think of getting rid of "implicitly declined" behavior for 
> > "cancelling operations"?
> > 
> > It seems that behavior is more driven by the implementation than 
> > intuitive api behavior; it e.g., forces frameworks to reason differently 
> > about operations executed in isolation vs. executed together. It seems 
> > having the identical behavior for both cases would both be easier to 
> > explain and also program against. The behavior that seems to make most 
> > sense for me would be to only ever implictly decline "untouched resources", 
> > e.g., if accepting offered `cpus:4` with `RESERVE(cpus:2, role) && 
> > UNRESERVE(cpus:2, role)` we would implicitly decline only `cpus:2`.
> 
> Chun-Hung Hsiao wrote:
> It seems to me that "cancelling operations" as something that are both 1. 
> very rare and 2. make little sense for frameworks, so I'm more like 
> delivering a fix for common cases without making the alrealy-messy code path 
> more complicated. WDYT? Also @bmahler what's your opinion on @bbannier's 
> suggestion? IIRC you mentioned something like some are designed behaviors 
> before, but I didn't know the context.
> 
> Benjamin Mahler wrote:
> Thanks for bringing this up, it's certainly a bit bizarre of a use case. 
> I think the more common case is UNRESERVE on its own, where it still seems a 
> bit bizarre that the "untouched" resources are declined with the filter and 
> the UNRESERVE resources are not filtered. That seems a bit arbitrary to me, 
> but I'm not sure what to do about it without allowing the framework to be 
> explicit about which part it wants to "decline and filter" when accepting, 
> and this requires an interface change.
> 
> Personally I would consider RESERVE+UNRESERVE to be "touching" those 
> resources, but I don't think we should worry about it in this patch (I assume 
> that wasn't your intent anyway, and you were more wanting to raise this topic 
> for discussion?)

What I worry most is that this edge case makes explaining suggested framework 
behavior harder ("should any of the offer operations in a single accept call 
cancel each other out you will not get offered the resources again until the 
default offer filter timeout expires (the timeout isn't up to you here)" -> 
framework defensively revives after each accept call if it has more work to 
do). Instead we would like frameworks to focus on getting their offer handling 
and decline behavior correct and only ever revive in exceptional scenarios 
(e.g., even "_new_ work arrived").

Since this patch tries to fix incorrect master behavior we should make sure to 
get the behavior somewhat right or else risk that frameworks implement 
suboptimal behavior which will be hard to unlearn. That being said, the fact 
that no framework author complained when this bug was introduced makes me worry 
that they either do not care about how fast offers arrive or already implement 
a overly pessimistc approach (e.g., revive whenever there is more work to do in 
their state machine).


- Benjamin


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


On April 23, 2019, 3:15 a.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> ---
> 
> (Updated April 23, 2019, 3:15 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
> https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly declined. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be declined.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 

Re: Review Request 70528: WIP: Update release guide to mention bintray.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70526', '70527', '70528']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3244/mesos-review-70528

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3244/mesos-review-70528/logs/mesos-tests.log):

```
I0423 17:27:49.511770 64684 master.cpp:] Disconnecting agent 
167a0c02-a81f-4eb1-b214-7304cee447d7-S0 at slave(501)@192.10.1.4:54939 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 17:27:49.511770 64684 master.cpp:3352] Deactivating agent 
167a0c02-a81f-4eb1-b214-7304cee447d7-S0 at slave(501)@192.10.1.4:54939 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 17:27:49.511770 66076 hierarchical.cpp:392] Removed framework 
167a0c02-a81f-4eb1-b214-7304cee447d7-
I0423 17:27:49.511770 66076 hierarchical.cpp:829] Agent 
167a0c02-a81f-4eb1-b214-7304cee447d7-S0 deactivated
I0423 17:27:49.511770 64684 containerizer.cpp:2576] Destroying container 
d2d25525-b016-47e4-8d92-9a5db21e84fd in RUNNING state
I0423 17:27:49.511770 64684 containerizer.cpp:3278] Transitioning the state of 
container d2d25525-b016-47e4-8d92-9a5db21e84fd from RUNNING to DESTROYING
I0423 17:27:49.511770 64684 launcher.cpp:161] Asked to destroy container 
d2d25525-b016-47e4-8d92-9a5db21e84fd
W0423 17:27:49.511770 73768 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=14204 to peer '192.10.1.4:57337': IO failed with error 
code: The specified network name is no longer available.

W0423 17:27:49.511770 73768 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=14280 to peer '192.10.1.4:57336': IO failed with error 
code: The specified network name is no longer available.

I0423 17:27:49.604877 76316 containerizer.cpp:3117] Container 
d2d25525-b016-47e4-8d92-9a5db21e84fd has exited
I0423 17:27:49.636494 74952 master.cpp:1135] Master terminating
I0423 17:27:49.637542 66076 hierarchical.cpp:680] Removed agent 
167a0c02-a81f-4eb1-b214-7304ce[   OK ] 
IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (733 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (750 ms total)

[--] Global test environment tear-down
[==] 1162 tests from 109 test cases ran. (589805 ms total)
[  PASSED  ] 1159 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

e447d7-S0
I0423 17:27:50.607642 73768 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 23, 2019, 7:32 a.m., Benno Evers wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70528/
> ---
> 
> (Updated April 23, 2019, 7:32 a.m.)
> 
> 
> Review request for mesos, Greg Mann and Till Toenshoff.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> WIP: Update release guide to mention bintray.
> 
> 
> Diffs
> -
> 
>   docs/release-guide.md a3ad2668a1953a7f20dd7209e122481ad8b30f17 
> 
> 
> Diff: https://reviews.apache.org/r/70528/diff/1/
> 
> 
> Testing
> ---
> 
> None yet; will probably beta-test this procedure for the 1.8.0 release and 
> then update this review once I know what needs to be done.
> 
> 
> Thanks,
> 
> Benno Evers
> 
>

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Benno Evers]

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


Fix it, then Ship it!




The change itself looks good to me, so all that follows below are fairly minor 
style comments.

One thing that we might think about is if we can somehow abstract out the 
iteration over all tasks itself, since it seems like it is being used in 
multiple places. However, I didn't really have a good idea of how this should 
look like, so I did not make a separate comment about that.


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


It looks like the `MESOS-` still needs to be updated.



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


Nit: I'd probably write this as

CHECK(slaves.recovered.contains(slaveId) || 
slaves.unreachable.contains(slaveId))

That way the code matches exactly what's written in the comment.



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


Nit: We could save one level of indentation (and more importantly one item 
on the reader's mental stack) by writing this as

if (framework == nullptr) {
  continue;
}



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


The return type here looks very dangerous: A correct implementation of 
`Owned<>` should destroy its contents when it goes out of scope.

I'm a bit torn here because I know it works with our current implementation 
of `Owned<>`, but it seems a bit odd to "exploit" the implementation details 
this way.

Maybe we should use `.find()` or `operator[]` instead?



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


The same comment as above also applies here, this seems to be leaning very 
heavily on the fact that `Owned` is in fact `shared_ptr`.


- Benno Evers


On April 22, 2019, 11:57 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70519/
> ---
> 
> (Updated April 22, 2019, 11:57 p.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch updates the master code responsible for marking
> agents as gone to properly transition tasks on agents which
> were previously marked as unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
>   src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
>   src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 
> 
> 
> Diff: https://reviews.apache.org/r/70519/diff/1/
> 
> 
> Testing
> ---
> 
> `make check`
> `bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
> --gtest_repeat=-1 --gtest_break_on_failure`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70528: WIP: Update release guide to mention bintray.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [70526, 70527, 70528]

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

- Mesos Reviewbot


On April 23, 2019, 2:32 p.m., Benno Evers wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70528/
> ---
> 
> (Updated April 23, 2019, 2:32 p.m.)
> 
> 
> Review request for mesos, Greg Mann and Till Toenshoff.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> WIP: Update release guide to mention bintray.
> 
> 
> Diffs
> -
> 
>   docs/release-guide.md a3ad2668a1953a7f20dd7209e122481ad8b30f17 
> 
> 
> Diff: https://reviews.apache.org/r/70528/diff/1/
> 
> 
> Testing
> ---
> 
> None yet; will probably beta-test this procedure for the 1.8.0 release and 
> then update this review once I know what needs to be done.
> 
> 
> Thanks,
> 
> Benno Evers
> 
>

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Benjamin Mahler]

> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > docs/scheduler-http-api.md
> > Line 132 (original), 132 (patched)
> > 
> >
> > What do you think of getting rid of "implicitly declined" behavior for 
> > "cancelling operations"?
> > 
> > It seems that behavior is more driven by the implementation than 
> > intuitive api behavior; it e.g., forces frameworks to reason differently 
> > about operations executed in isolation vs. executed together. It seems 
> > having the identical behavior for both cases would both be easier to 
> > explain and also program against. The behavior that seems to make most 
> > sense for me would be to only ever implictly decline "untouched resources", 
> > e.g., if accepting offered `cpus:4` with `RESERVE(cpus:2, role) && 
> > UNRESERVE(cpus:2, role)` we would implicitly decline only `cpus:2`.
> 
> Chun-Hung Hsiao wrote:
> It seems to me that "cancelling operations" as something that are both 1. 
> very rare and 2. make little sense for frameworks, so I'm more like 
> delivering a fix for common cases without making the alrealy-messy code path 
> more complicated. WDYT? Also @bmahler what's your opinion on @bbannier's 
> suggestion? IIRC you mentioned something like some are designed behaviors 
> before, but I didn't know the context.

Thanks for bringing this up, it's certainly a bit bizarre of a use case. I 
think the more common case is UNRESERVE on its own, where it still seems a bit 
bizarre that the "untouched" resources are declined with the filter and the 
UNRESERVE resources are not filtered. That seems a bit arbitrary to me, but I'm 
not sure what to do about it without allowing the framework to be explicit 
about which part it wants to "decline and filter" when accepting, and this 
requires an interface change.

Personally I would consider RESERVE+UNRESERVE to be "touching" those resources, 
but I don't think we should worry about it in this patch (I assume that wasn't 
your intent anyway, and you were more wanting to raise this topic for 
discussion?)


> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > src/master/master.cpp
> > Lines 5963-5964 (original), 5983-5984 (patched)
> > 
> >
> > Is this a workaround we need until MESOS-4553 gets resolved? If it is, 
> > let's add a `TODO`.
> 
> Chun-Hung Hsiao wrote:
> I don't know actually lol. I just copied it from 
> https://github.com/apache/mesos/blob/45c9788618e7123f408a1dffcf6772a1285cd2e5/src/master/master.cpp#L10969-L10972,
>  as @mzhu suggested that if there's an allocation in between there might be 
> offer fragmentation. Is this a workaround for MESOS-4553?

Well, one could say all the interactions with the allocator around offers are a 
"workaround" until MESOS-4553 is done :)

I would say that the pause/resume here is more a workaround of the limited 
recoverResources interface (i.e. it doesn't let you specify a collection of 
resources and filters, so we need to perform two calls). The only issue with 
pause/resume is: https://issues.apache.org/jira/browse/MESOS-9734


- Benjamin


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


On April 23, 2019, 1:15 a.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> ---
> 
> (Updated April 23, 2019, 1:15 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
> https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly declined. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be declined.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Chun-Hung Hsiao]

> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > docs/scheduler-http-api.md
> > Line 132 (original), 132 (patched)
> > 
> >
> > What do you think of getting rid of "implicitly declined" behavior for 
> > "cancelling operations"?
> > 
> > It seems that behavior is more driven by the implementation than 
> > intuitive api behavior; it e.g., forces frameworks to reason differently 
> > about operations executed in isolation vs. executed together. It seems 
> > having the identical behavior for both cases would both be easier to 
> > explain and also program against. The behavior that seems to make most 
> > sense for me would be to only ever implictly decline "untouched resources", 
> > e.g., if accepting offered `cpus:4` with `RESERVE(cpus:2, role) && 
> > UNRESERVE(cpus:2, role)` we would implicitly decline only `cpus:2`.

It seems to me that "cancelling operations" as something that are both 1. very 
rare and 2. make little sense for frameworks, so I'm more like delivering a fix 
for common cases without making the alrealy-messy code path more complicated. 
WDYT? Also @bmahler what's your opinion on @bbannier's suggestion? IIRC you 
mentioned something like some are designed behaviors before, but I didn't know 
the context.


> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > src/master/master.cpp
> > Lines 5963-5964 (original), 5983-5984 (patched)
> > 
> >
> > Is this a workaround we need until MESOS-4553 gets resolved? If it is, 
> > let's add a `TODO`.

I don't know actually lol. I just copied it from 
https://github.com/apache/mesos/blob/45c9788618e7123f408a1dffcf6772a1285cd2e5/src/master/master.cpp#L10969-L10972,
 as @mzhu suggested that if there's an allocation in between there might be 
offer fragmentation. Is this a workaround for MESOS-4553?


> On April 23, 2019, 10:47 a.m., Benjamin Bannier wrote:
> > src/tests/slave_tests.cpp
> > Lines 6499 (patched)
> > 
> >
> > Since the changes in this patch are strongly related to behavior 
> > framework authors need to reason about I strongly feel that we must add a 
> > test for the expected behavior.

I could add a unit test in a separated patch. This patch itself will be 
backported, after discussed with @bmahler.


- Chun-Hung


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


On April 23, 2019, 1:15 a.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> ---
> 
> (Updated April 23, 2019, 1:15 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
> https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly declined. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be declined.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70518: Fixed a memory leak in the master's 'removeTask()' helper.

[Benno Evers]

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


Ship it!




Ship It!

- Benno Evers


On April 22, 2019, 11:45 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70518/
> ---
> 
> (Updated April 22, 2019, 11:45 p.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Previously, all removed tasks were added to the
> `slaves.unreachableTasks` map. This patch adds a conditional
> so that removed tasks are only added to that structure when
> they are being marked unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
> 
> 
> Diff: https://reviews.apache.org/r/70518/diff/1/
> 
> 
> Testing
> ---
> 
> `make check`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Review Request 70527: Updated Bintray URL in docs.

[Benno Evers]

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

Review request for mesos, Greg Mann and Till Toenshoff.


Repository: mesos


Description
---

Updated Bintray URL in docs.


Diffs
-

  docs/binary-packages.md 462e732246aa3f3a69f243e512fa73012341 


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


Testing
---

Opened the modified links in a browser to ensure no typos.


Thanks,

Benno Evers

Review Request 70528: WIP: Update release guide to mention bintray.

[Benno Evers]

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

Review request for mesos, Greg Mann and Till Toenshoff.


Repository: mesos


Description
---

WIP: Update release guide to mention bintray.


Diffs
-

  docs/release-guide.md a3ad2668a1953a7f20dd7209e122481ad8b30f17 


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


Testing
---

None yet; will probably beta-test this procedure for the 1.8.0 release and then 
update this review once I know what needs to be done.


Thanks,

Benno Evers

Review Request 70526: Rearranged 'Downloads' page and updated bintray URL.

[Benno Evers]

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

Review request for mesos, Greg Mann and Till Toenshoff.


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


Repository: mesos


Description
---

Updated the bintray link on the `Downloads` page to point
to the `apache/mesos` account instead of the `mesos`
account.

In addition, several minor formatting changes were done:

  * Added a space after the colon in the `Getting older
Mesos binaries` section.

  * Moved links to the getting started guide to the top
of the document.

  * Used a list to present the download links to the latest
stable release.

  * Used `` instead of `` tags for the link to the
ASF git repository.


Diffs
-

  site/source/downloads.html.erb d5a165c71378a7c268b9c2e73b60902d632463fb 


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


Testing
---

Visual inspection after using Firefox to edit the HTML: 
https://drive.google.com/file/d/1PuLGmb3h3pj3xNXciVGWPQzGBHJqHvk5/view?usp=sharing


Thanks,

Benno Evers

Re: Review Request 70133: Removed unnecessary accept filters in SLRP tests.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70132', '70521', '70133']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3242/mesos-review-70133

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3242/mesos-review-70133/logs/mesos-tests.log):

```
I0423 12:26:20.012372 74948 master.cpp:] Disconnecting agent 
0a068c4b-f399-4887-a3c9-ae3eea705cfc-S0 at slave(501)@192.10.1.4:52137 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 12:26:20.012372 74948 master.cpp:3352] Deactivating agent 
0a068c4b-f399-4887-a3c9-ae3eea705cfc-S0 at slave(501)@192.10.1.4:52137 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 12:26:20.013376 71464 hierarchical.cpp:392] Removed framework 
0a068c4b-f399-4887-a3c9-ae3eea705cfc-
I0423 12:26:20.013376 71464 hierarchical.cpp:829] Agent 
0a068c4b-f399-4887-a3c9-ae3eea705cfc-S0 deactivated
I0423 12:26:20.014398 72056 containerizer.cpp:2576] Destroying container 
b00a3bb1-9df7-4322-ab24-ad0ff75733a5 in RUNNING state
I0423 12:26:20.014398 72056 containerizer.cpp:3278] Transitioning the state of 
container b00a3bb1-9df7-4322-ab24-ad0ff75733a5 from RUNNING to DESTROYING
I0423 12:26:20.014398 72056 launcher.cpp:161] Asked to destroy container 
b00a3bb1-9df7-4322-ab24-ad0ff75733a5
W0423 12:26:20.015440 73000 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=1184 to peer '192.10.1.4:54519': IO failed with error 
code: The specified network name is no longer available.

W0423 12:26:20.016374 73000 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=1224 to peer '192.10.1.4:54520': IO failed with e[  
 OK ] IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (794 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (812 ms total)

[--] Global test environment tear-down
[==] 1162 tests from 109 test cases ran. (588932 ms total)
[  PASSED  ] 1159 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

rror code: The specified network name is no longer available.

I0423 12:26:20.085477 74172 containerizer.cpp:3117] Container 
b00a3bb1-9df7-4322-ab24-ad0ff75733a5 has exited
I0423 12:26:20.119426 74172 master.cpp:1135] Master terminating
I0423 12:26:20.120602 74728 hierarchical.cpp:680] Removed agent 
0a068c4b-f399-4887-a3c9-ae3eea705cfc-S0
I0423 12:26:21.104396 73000 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 9, 2019, 9:21 p.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70133/
> ---
> 
> (Updated April 9, 2019, 9:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier and Meng Zhu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removed unnecessary accept filters in SLRP tests.
> 
> 
> Diffs
> -
> 
>   src/tests/storage_local_resource_provider_tests.cpp 
> bd35150200a23ba57408f5d64a975f8a2f062018 
> 
> 
> Diff: https://reviews.apache.org/r/70133/diff/2/
> 
> 
> Testing
> ---
> 
> `sudo make check`
> 
> Especially, tested that each of the three modified tests finishes in 5 
> seconds.
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70132: Do not implicitly decline speculatively converted resources.

[Benjamin Bannier]

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




docs/scheduler-http-api.md
Line 132 (original), 132 (patched)


What do you think of getting rid of "implicitly declined" behavior for 
"cancelling operations"?

It seems that behavior is more driven by the implementation than intuitive 
api behavior; it e.g., forces frameworks to reason differently about operations 
executed in isolation vs. executed together. It seems having the identical 
behavior for both cases would both be easier to explain and also program 
against. The behavior that seems to make most sense for me would be to only 
ever implictly decline "untouched resources", e.g., if accepting offered 
`cpus:4` with `RESERVE(cpus:2, role) && UNRESERVE(cpus:2, role)` we would 
implicitly decline only `cpus:2`.



src/master/master.cpp
Lines 5963-5964 (original), 5983-5984 (patched)


Is this a workaround we need until MESOS-4553 gets resolved? If it is, 
let's add a `TODO`.



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


Since the changes in this patch are strongly related to behavior framework 
authors need to reason about I strongly feel that we must add a test for the 
expected behavior.


- Benjamin Bannier


On April 23, 2019, 3:15 a.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70132/
> ---
> 
> (Updated April 23, 2019, 3:15 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Benjamin Mahler, and Meng Zhu.
> 
> 
> Bugs: MESOS-9616
> https://issues.apache.org/jira/browse/MESOS-9616
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Currently if a framework accepts an offer to perform pipelined
> operations, e.g., reserving resource, without a final consumer, the
> converted resources will be implicitly declined. This is an undesired
> behavior as the framework might want to reserve one resource first but
> launch a task later in the next allocation cycle. This patch fixes this
> behavior.
> 
> But, if the framework accepts an offers with multiple operations that
> cancel out each other, the resources consumed by these operations are
> still considered unused and will be declined.
> 
> 
> Diffs
> -
> 
>   docs/scheduler-http-api.md a5327c229142267836f327f9c382ef50b7e334db 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/slave_tests.cpp b1c3a01031b917fb9773c8c890a8f88838870559 
> 
> 
> Diff: https://reviews.apache.org/r/70132/diff/5/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70519: Transitioned tasks when an unreachable agent is marked as gone.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70518', '70519']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3240/mesos-review-70519

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3240/mesos-review-70519/logs/mesos-tests.log):

```
I0423 08:37:41.367103 58160 master.cpp:] Disconnecting agent 
b1762a03-e55a-4dd1-98bd-7a15e69670cb-S0 at slave(503)@192.10.1.4:49323 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 08:37:41.367103 58160 master.cpp:3352] Deactivating agent 
b1762a03-e55a-4dd1-98bd-7a15e69670cb-S0 at slave(503)@192.10.1.4:49323 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 08:37:41.367103 67200 hierarchical.cpp:392] Removed framework 
b1762a03-e55a-4dd1-98bd-7a15e69670cb-
I0423 08:37:41.367103 67200 hierarchical.cpp:829] Agent 
b1762a03-e55a-4dd1-98bd-7a15e69670cb-S0 deactivated
I0423 08:37:41.369081 67680 containerizer.cpp:2576] Destroying container 
9efa696d-d7f1-45a1-8016-7d8afb501b86 in RUNNING state
I0423 08:37:41.369081 67680 containerizer.cpp:3278] Transitioning the state of 
container 9efa696d-d7f1-45a1-8016-7d8afb501b86 from RUNNING to DESTROYING
I0423 08:37:41.369081 67680 launcher.cpp:161] Asked to destroy container 
9efa696d-d7f1-45a1-8016-7d8afb501b86
W0423 08:37:41.371099 75280 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=10412 to peer '192.10.1.4:51761': IO failed with error 
code: The specified network name is no lo[   OK ] 
IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (882 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (902 ms total)

[--] Global test environment tear-down
[==] 1164 tests from 109 test cases ran. (596228 ms total)
[  PASSED  ] 1161 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

nger available.

W0423 08:37:41.371099 75280 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=10244 to peer '192.10.1.4:51760': IO failed with error 
code: The specified network name is no longer available.

I0423 08:37:41.414130 73912 containerizer.cpp:3117] Container 
9efa696d-d7f1-45a1-8016-7d8afb501b86 has exited
I0423 08:37:41.448145 72796 master.cpp:1135] Master terminating
I0423 08:37:41.450112 67200 hierarchical.cpp:680] Removed agent 
b1762a03-e55a-4dd1-98bd-7a15e69670cb-S0
I0423 08:37:42.777107 75280 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 22, 2019, 11:57 p.m., Greg Mann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70519/
> ---
> 
> (Updated April 22, 2019, 11:57 p.m.)
> 
> 
> Review request for mesos, Benno Evers, Gastón Kleiman, Joseph Wu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-9545
> https://issues.apache.org/jira/browse/MESOS-9545
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> This patch updates the master code responsible for marking
> agents as gone to properly transition tasks on agents which
> were previously marked as unreachable.
> 
> 
> Diffs
> -
> 
>   src/master/framework.cpp 05f5514c589b2dba08afe77281e5fbc4e29f232b 
>   src/master/http.cpp e7a92d0f554ba4cafaee5a75f09b46eb1bf4a310 
>   src/master/master.hpp 94891af9deeaddbfc9d6eabb243aed97f7b7 
>   src/master/master.cpp ad54ae217863a08f4e6d743b39c176b171353084 
>   src/tests/api_tests.cpp e76417a9098281265b3411c18767bfcc2f624b6f 
> 
> 
> Diff: https://reviews.apache.org/r/70519/diff/1/
> 
> 
> Testing
> ---
> 
> `make check`
> `bin/mesos-tests.sh --gtest_filter="*UnreachableAgentMarkedGone*" 
> --gtest_repeat=-1 --gtest_break_on_failure`
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Re: Review Request 70133: Removed unnecessary accept filters in SLRP tests.

[Mesos Reviewbot]

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



Patch looks great!

Reviews applied: [70132, 70521, 70133]

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

- Mesos Reviewbot


On April 9, 2019, 9:21 p.m., Chun-Hung Hsiao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70133/
> ---
> 
> (Updated April 9, 2019, 9:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier and Meng Zhu.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Removed unnecessary accept filters in SLRP tests.
> 
> 
> Diffs
> -
> 
>   src/tests/storage_local_resource_provider_tests.cpp 
> bd35150200a23ba57408f5d64a975f8a2f062018 
> 
> 
> Diff: https://reviews.apache.org/r/70133/diff/2/
> 
> 
> Testing
> ---
> 
> `sudo make check`
> 
> Especially, tested that each of the three modified tests finishes in 5 
> seconds.
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>

Re: Review Request 70508: Fixed the flaky ExamplesTest.DynamicReservationFramework.

[Mesos Reviewbot Windows]

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



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

Reviews applied: `['70132', '70508']`

Failed command: `Start-MesosCITesting`

All the build artifacts available at: 
http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3238/mesos-review-70508

Relevant logs:

- 
[mesos-tests.log](http://dcos-win.westus2.cloudapp.azure.com/artifacts/mesos-reviewbot-testing/3238/mesos-review-70508/logs/mesos-tests.log):

```
I0423 07:23:27.538352 70628 master.cpp:] Disconnecting agent 
4fd80e2a-3f22-4bb3-a43f-c9b747d99501-S0 at slave(501)@192.10.1.4:63077 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 07:23:27.539352 70628 master.cpp:3352] Deactivating agent 
4fd80e2a-3f22-4bb3-a43f-c9b747d99501-S0 at slave(501)@192.10.1.4:63077 
(windows-01.chtsmhjxogyevckjfayqqcnjda.xx.internal.cloudapp.net)
I0423 07:23:27.539352 70164 hierarchical.cpp:392] Removed framework 
4fd80e2a-3f22-4bb3-a43f-c9b747d99501-
I0423 07:23:27.539352 70164 hierarchical.cpp:829] Agent 
4fd80e2a-3f22-4bb3-a43f-c9b747d99501-S0 deactivated
I0423 07:23:27.539352 74600 containerizer.cpp:2576] Destroying container 
da45affc-a0d6-4ba1-835c-8f74d50d29b0 in RUNNING state
I0423 07:23:27.539352 74600 containerizer.cpp:3278] Transitioning the state of 
container da45affc-a0d6-4ba1-835c-8f74d50d29b0 from RUNNING to DESTROYING
I0423 07:23:27.539352 74600 launcher.cpp:[   OK ] 
IsolationFlag/MemoryIsolatorTest.ROOT_MemUsage/0 (683 ms)
[--] 1 test from IsolationFlag/MemoryIsolatorTest (701 ms total)

[--] Global test environment tear-down
[==] 1162 tests from 109 test cases ran. (595934 ms total)
[  PASSED  ] 1159 tests.
[  FAILED  ] 3 tests, listed below:
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchManifest
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_FetchImage
[  FAILED  ] DockerFetcherPluginTest.INTERNET_CURL_InvokeFetchByName

 3 FAILED TESTS
  YOU HAVE 233 DISABLED TESTS

161] Asked to destroy container da45affc-a0d6-4ba1-835c-8f74d50d29b0
W0423 07:23:27.541344 74432 process.cpp:1423] Failed to recv on socket 
WindowsFD::Type::SOCKET=6068 to peer '192.10.1.4:65468': IO failed with error 
code: The specified network name is no longer available.

W0423 07:23:27.542357 74432 process.cpp:838] Failed to recv on socket 
WindowsFD::Type::SOCKET=4144 to peer '192.10.1.4:65469': IO failed with error 
code: The specified network name is no longer available.

I0423 07:23:27.548353 73712 containerizer.cpp:3117] Container 
da45affc-a0d6-4ba1-835c-8f74d50d29b0 has exited
I0423 07:23:27.577365 59656 master.cpp:1135] Master terminating
I0423 07:23:27.578368 63304 hierarchical.cpp:680] Removed agent 
4fd80e2a-3f22-4bb3-a43f-c9b747d99501-S0
I0423 07:23:28.626175 74432 process.cpp:927] Stopped the socket accept loop
```

- Mesos Reviewbot Windows


On April 22, 2019, 4:47 p.m., Benjamin Mahler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/70508/
> ---
> 
> (Updated April 22, 2019, 4:47 p.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Meng Zhu.
> 
> 
> Bugs: MESOS-5804
> https://issues.apache.org/jira/browse/MESOS-5804
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> The test failed in MESOS-5804 due to the following race:
> 
>   1. Framework launches task T, moves from RESERVED to
>  TASK_RUNNING state.
>   2. Allocation cycle triggers and will send the unreserved
>  resources to the framework.
>   3. Before the offer gets to the framework, task T finishes and
>  framework moves from TASK_RUNNING to RESERVED.
>   4. In the RESERVED state, the framework expects the reservation
>  in the offer. But, it's coming in a later offer, and the one
>  that arrives is for the unreserved resources since it was
>  generated while the task was still running.
> 
> Tne fix applied here for this specific race is to use a 2 week
> filter rather than a 0 second filter. That would ensure that the
> unreserved resources do not get re-offered to the framework on
> their own. However, this fix does not work until MESOS-9616 is
> resolved.
> 
> 
> Diffs
> -
> 
>   src/examples/dynamic_reservation_framework.cpp 
> f9c7dfe46a1e8dd1bc8eae45ed1b65b7a6d60dfc 
> 
> 
> Diff: https://reviews.apache.org/r/70508/diff/1/
> 
> 
> Testing
> ---
> 
> Test passes with https://reviews.apache.org/r/70132/ applied.
> 
> 
> Thanks,
> 
> Benjamin Mahler
> 
>