Re: Review Request 64978: Made task's volume directory visible in the /files endpoints.

[Qian Zhang]

> On Jan. 9, 2018, 8:04 a.m., Vinod Kone wrote:
> > src/slave/slave.cpp
> > Lines 9221-9246 (patched)
> > 
> >
> > Kill this. See above comments.
> 
> Qian Zhang wrote:
> The reason I did this change is, only doing detach in `removeExecutor` 
> and `recoverExecutor` can not handle a corner case: Say a default executor 
> launches a large number of tasks (say the number of tasks is greater than 
> `MAX_COMPLETED_TASKS_PER_EXECUTOR`), and then all the tasks finishes, so 
> there will be some old tasks automatically removed from 
> `Executor::completedTasks` (since it is `boost::circular_buffer` with size 
> `MAX_COMPLETED_TASKS_PER_EXECUTOR`). When `removeExecutor` is called 
> eventually, we will be missed to do the detach for those old tasks since we 
> can not find them anywhere, that is kind of leak.

Fixed the issue mentioned in my previous comment by doing detach for the first 
task before pushing a task into a full `Executor::completedTasks`.


- Qian


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


On Jan. 15, 2018, 2:21 p.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64978/
> ---
> 
> (Updated Jan. 15, 2018, 2:21 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Gilbert Song, Jie Yu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-8279
> https://issues.apache.org/jira/browse/MESOS-8279
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> In MESOS-7225, we made a task can access any volumes specified in its
> disk resources from its own sandbox by introducing a workaround to the
> default executor, i.e., add a `SANDBOX_PATH` volume with type `PARENT`
> to the corresponding nested container. It will be translated into a bind
> mount in the nested container's mount namespace, thus not visible in the
> host mount namespace, that means the task's volume directory can not be
> visible in Mesos UI since it operates in the host mount namespace.
> 
> In this patch, to make the task's volume directory visible in Mesos UI,
> we attached the executor's volume directory to it, so when users browse
> task's volume directory in Mesos UI, what they actually browse is the
> executor's volume directory. Note when calling `Files::attach()`, the
> third argument `authorized` is not specified, that is because it is
> already specified when we do the attach for the executor's sandbox and
> it is also applied to the executor's tasks.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.hpp ef0eae21af811cc09f43cd1d4c4ccc0c33cbeb39 
>   src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 
> 
> 
> Diff: https://reviews.apache.org/r/64978/diff/4/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 64978: Made task's volume directory visible in the /files endpoints.

[Qian Zhang]

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

(Updated Jan. 15, 2018, 2:21 p.m.)


Review request for mesos, Benjamin Mahler, Gilbert Song, Jie Yu, and Vinod Kone.


Changes
---

Addressed comments.


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


Repository: mesos


Description
---

In MESOS-7225, we made a task can access any volumes specified in its
disk resources from its own sandbox by introducing a workaround to the
default executor, i.e., add a `SANDBOX_PATH` volume with type `PARENT`
to the corresponding nested container. It will be translated into a bind
mount in the nested container's mount namespace, thus not visible in the
host mount namespace, that means the task's volume directory can not be
visible in Mesos UI since it operates in the host mount namespace.

In this patch, to make the task's volume directory visible in Mesos UI,
we attached the executor's volume directory to it, so when users browse
task's volume directory in Mesos UI, what they actually browse is the
executor's volume directory. Note when calling `Files::attach()`, the
third argument `authorized` is not specified, that is because it is
already specified when we do the attach for the executor's sandbox and
it is also applied to the executor's tasks.


Diffs (updated)
-

  src/slave/slave.hpp ef0eae21af811cc09f43cd1d4c4ccc0c33cbeb39 
  src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 


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

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


Testing
---

sudo make check


Thanks,

Qian Zhang

Re: Review Request 64857: Updated example frameworks for mesos-local.

[Mesos Reviewbot Windows]

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



PASS: Mesos patch 64857 was successfully built and tested.

Reviews applied: `['64846', '64847', '64848', '64849', '64857']`

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

- Mesos Reviewbot Windows


On Jan. 15, 2018, 12:29 a.m., Till Toenshoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64857/
> ---
> 
> (Updated Jan. 15, 2018, 12:29 a.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov, Armand Grillet, Greg Mann, 
> Kapil Arya, and Vinod Kone.
> 
> 
> Bugs: MESOS-8357 and MESOS-8361
> https://issues.apache.org/jira/browse/MESOS-8357
> https://issues.apache.org/jira/browse/MESOS-8361
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Unifies handling of 'local' when supplied for the '--master' flag.
> 
> 
> Diffs
> -
> 
>   src/examples/balloon_framework.cpp 410966e64aa3f146a88c00babaa51b499dd24d36 
>   src/examples/disk_full_framework.cpp 
> d75f769538d17229bdbf332ea7513b1aa8d7c334 
>   src/examples/docker_no_executor_framework.cpp 
> 1fa408d3847d414c23eed8334db8de02e84cf764 
>   src/examples/dynamic_reservation_framework.cpp 
> 538fbe8847a1b1dcbfe48ad0e3678797801a12f5 
>   src/examples/load_generator_framework.cpp 
> 42867992eba8699cab5b70c62a24b87446139406 
>   src/examples/long_lived_framework.cpp 
> 943160d5a42e02cf05fe92999233ce2e792849fd 
>   src/examples/no_executor_framework.cpp 
> 972ef777cec07d1030af208daef69ebe606d071e 
>   src/examples/test_framework.cpp acf1faf1523c8c03483dfafbc8f8e245322527e4 
>   src/examples/test_http_framework.cpp 
> 482f65efc15a7bac52c33a57b2b876191249410a 
> 
> 
> Diff: https://reviews.apache.org/r/64857/diff/3/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Till Toenshoff
> 
>

Re: Review Request 65156: Detached the virtual paths regardless of the result of gc.

[Qian Zhang]

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

(Updated Jan. 15, 2018, 9:16 a.m.)


Review request for mesos and Vinod Kone.


Changes
---

Updated the description.


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


Repository: mesos


Description (updated)
---

Previously we only detach the following paths when the gc for the
executor's sandbox succeeds.
  1. /agent_workdir/frameworks/FID/executors/EID/runs/CID
  2. /agent_workdir/frameworks/FID/executors/EID/runs/latest
  3. /frameworks/FID/executors/EID/runs/latest

But the problem is, such gc may not always succeed, e.g., it may fail
due to the parent directory of the executor's sandbox already gc'ed.

Now in this patch, we will detach those paths regardless of the result
of gc.


Diffs (updated)
-

  src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 


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

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


Testing
---


Thanks,

Qian Zhang

Re: Review Request 65156: Detached the virtual paths regardless of the result of gc.

[Qian Zhang]

> On Jan. 15, 2018, 3:01 a.m., Vinod Kone wrote:
> > Can you expand on the description on why this change is necessary?

Done.


- Qian


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


On Jan. 15, 2018, 9:16 a.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65156/
> ---
> 
> (Updated Jan. 15, 2018, 9:16 a.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-8444
> https://issues.apache.org/jira/browse/MESOS-8444
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Previously we only detach the following paths when the gc for the
> executor's sandbox succeeds.
>   1. /agent_workdir/frameworks/FID/executors/EID/runs/CID
>   2. /agent_workdir/frameworks/FID/executors/EID/runs/latest
>   3. /frameworks/FID/executors/EID/runs/latest
> 
> But the problem is, such gc may not always succeed, e.g., it may fail
> due to the parent directory of the executor's sandbox already gc'ed.
> 
> Now in this patch, we will detach those paths regardless of the result
> of gc.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 
> 
> 
> Diff: https://reviews.apache.org/r/65156/diff/2/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 64848: Updated example frameworks to make use of added flags.

[Till Toenshoff]

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

(Updated Jan. 15, 2018, 12:29 a.m.)


Review request for mesos, Alexander Rukletsov, Armand Grillet, Greg Mann, Kapil 
Arya, and Vinod Kone.


Changes
---

Further unification of the flags.


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


Repository: mesos


Description
---

The example frameworks now consistently rely on a set of common flags
for parameterizing. This unifies parameter names, descriptions and
validation for those examples.


Diffs (updated)
-

  src/examples/balloon_framework.cpp 410966e64aa3f146a88c00babaa51b499dd24d36 
  src/examples/disk_full_framework.cpp d75f769538d17229bdbf332ea7513b1aa8d7c334 
  src/examples/docker_no_executor_framework.cpp 
1fa408d3847d414c23eed8334db8de02e84cf764 
  src/examples/dynamic_reservation_framework.cpp 
538fbe8847a1b1dcbfe48ad0e3678797801a12f5 
  src/examples/load_generator_framework.cpp 
42867992eba8699cab5b70c62a24b87446139406 
  src/examples/long_lived_framework.cpp 
943160d5a42e02cf05fe92999233ce2e792849fd 
  src/examples/no_executor_framework.cpp 
972ef777cec07d1030af208daef69ebe606d071e 
  src/examples/persistent_volume_framework.cpp 
71db39d7743d31ea34c2aed579d7a1ef2ed95687 
  src/examples/test_framework.cpp acf1faf1523c8c03483dfafbc8f8e245322527e4 
  src/examples/test_http_framework.cpp 482f65efc15a7bac52c33a57b2b876191249410a 


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

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 64857: Updated example frameworks for mesos-local.

[Till Toenshoff]

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

(Updated Jan. 15, 2018, 12:29 a.m.)


Review request for mesos, Alexander Rukletsov, Armand Grillet, Greg Mann, Kapil 
Arya, and Vinod Kone.


Bugs: MESOS-8357 and MESOS-8361
https://issues.apache.org/jira/browse/MESOS-8357
https://issues.apache.org/jira/browse/MESOS-8361


Repository: mesos


Description
---

Unifies handling of 'local' when supplied for the '--master' flag.


Diffs (updated)
-

  src/examples/balloon_framework.cpp 410966e64aa3f146a88c00babaa51b499dd24d36 
  src/examples/disk_full_framework.cpp d75f769538d17229bdbf332ea7513b1aa8d7c334 
  src/examples/docker_no_executor_framework.cpp 
1fa408d3847d414c23eed8334db8de02e84cf764 
  src/examples/dynamic_reservation_framework.cpp 
538fbe8847a1b1dcbfe48ad0e3678797801a12f5 
  src/examples/load_generator_framework.cpp 
42867992eba8699cab5b70c62a24b87446139406 
  src/examples/long_lived_framework.cpp 
943160d5a42e02cf05fe92999233ce2e792849fd 
  src/examples/no_executor_framework.cpp 
972ef777cec07d1030af208daef69ebe606d071e 
  src/examples/test_framework.cpp acf1faf1523c8c03483dfafbc8f8e245322527e4 
  src/examples/test_http_framework.cpp 482f65efc15a7bac52c33a57b2b876191249410a 


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

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 64847: Added collection of example framework flag definitions.

[Till Toenshoff]

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

(Updated Jan. 15, 2018, 12:29 a.m.)


Review request for mesos, Alexander Rukletsov, Armand Grillet, Greg Mann, Kapil 
Arya, and Vinod Kone.


Changes
---

Unified the flags further.


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


Repository: mesos


Description
---

Adds a set if flags exclusively used by our example frameworks. This
enhancement aids in unifying the user experience when tinkering with
our examples.


Diffs (updated)
-

  src/examples/flags.hpp PRE-CREATION 


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

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 64849: Added authentication to some example frameworks.

[Till Toenshoff]

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

(Updated Jan. 15, 2018, 12:29 a.m.)


Review request for mesos, Alexander Rukletsov, Armand Grillet, Greg Mann, Kapil 
Arya, and Vinod Kone.


Bugs: MESOS-5362 and MESOS-8357
https://issues.apache.org/jira/browse/MESOS-5362
https://issues.apache.org/jira/browse/MESOS-8357


Repository: mesos


Description
---

All example frameworks now support authenticating when registering
to the master.


Diffs (updated)
-

  src/examples/dynamic_reservation_framework.cpp 
538fbe8847a1b1dcbfe48ad0e3678797801a12f5 
  src/examples/persistent_volume_framework.cpp 
71db39d7743d31ea34c2aed579d7a1ef2ed95687 
  src/examples/test_http_framework.cpp 482f65efc15a7bac52c33a57b2b876191249410a 
  src/tests/persistent_volume_framework_test.sh 
2ab22c03e573d4801c73957f9cad2939b3d3174b 


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

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


Testing
---

make check


Thanks,

Till Toenshoff

Re: Review Request 64911: Refactored connection logic in libprocess.

[Mesos Reviewbot Windows]

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



FAIL: Failed to apply the dependent review: 55323.

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

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

Relevant logs:

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

```
error: patch failed: src/master/master.hpp:2158
error: src/master/master.hpp: patch does not apply
```

- Mesos Reviewbot Windows


On Jan. 3, 2018, 7:23 a.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64911/
> ---
> 
> (Updated Jan. 3, 2018, 7:23 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Refactored connection logic in libprocess.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/process.cpp 
> 75cf1d3b6d3d257ba9bc81c68017a74a6511cebf 
>   3rdparty/libprocess/src/socket_manager.hpp 
> dd4d111c4ae579420060e547dd12f8f0711c 
> 
> 
> Diff: https://reviews.apache.org/r/64911/diff/2/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Re: Review Request 64911: Refactored connection logic in libprocess.

[Benjamin Mahler]

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



Refactoring looks good, but I was curious about a change below that seems to 
alter the semantics of RECONNECT and introduces a race where the first socket 
wins and the RECONNECT loses.

I'm also a little puzzled still at what is preventing two concurrent send loops 
on a socket.


3rdparty/libprocess/src/process.cpp
Line 1677 (original), 1555 (patched)


newline?



3rdparty/libprocess/src/process.cpp
Lines 1677-1683 (original), 1555-1562 (patched)


Just to clarify, this is an existing issue with the old code as well, right?



3rdparty/libprocess/src/process.cpp
Lines 1571-1575 (patched)


It might not be necessary, but it does seem helpful to spell out that this 
can happen.



3rdparty/libprocess/src/process.cpp
Lines 1657-1659 (patched)


Why did you need this? It looks like you're already capturing with = in 
recover so you could look at `socket` anyway?



3rdparty/libprocess/src/process.cpp
Lines 1758-1761 (original), 1669-1672 (patched)


Shouldn't we be CHECKing here that socket.kind is SSL? And maybe also that 
the future isFailed?



3rdparty/libprocess/src/process.cpp
Lines 1697-1703 (patched)


It looks to me like you need to do this in the mutex? Otherwise it seems 
like the semantics are changing:

Before: FWICT, a RECONNECT will always replace previous socket that's 
getting connected.

After: FWICT, we check here under the mutex that socket is still contained, 
then RECONNECT swaps it, then we swap it again here on the first connect 
socket. So the first socket can win the race?



3rdparty/libprocess/src/process.cpp
Lines 1805-1822 (original), 1714-1738 (patched)


Hm.. I was expecting `connect` to return once connected, but this .then 
returning the receive loop makes it look like `connect` will return after the 
receive loop finishes reading..? Am I mis-reading this?



3rdparty/libprocess/src/socket_manager.hpp
Lines 53-54 (patched)


Hm.. this could use some more detail about what a downgrade is and when we 
downgrade? E.g.

```
Helper to connect the socket to the provided address.
If the initial connection attempt was done over SSL and
fails, we will attempt to "downgrade" the connection by
re-connecting without SSL. The "downgrade" can be
enabled or disabled via a flag / environment variable.
```


- Benjamin Mahler


On Jan. 3, 2018, 7:23 a.m., Benjamin Hindman wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64911/
> ---
> 
> (Updated Jan. 3, 2018, 7:23 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Refactored connection logic in libprocess.
> 
> 
> Diffs
> -
> 
>   3rdparty/libprocess/src/process.cpp 
> 75cf1d3b6d3d257ba9bc81c68017a74a6511cebf 
>   3rdparty/libprocess/src/socket_manager.hpp 
> dd4d111c4ae579420060e547dd12f8f0711c 
> 
> 
> Diff: https://reviews.apache.org/r/64911/diff/2/
> 
> 
> Testing
> ---
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Re: Review Request 64978: Made task's volume directory visible in the /files endpoints.

[Vinod Kone]

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




src/slave/slave.cpp
Lines 2813 (patched)


can you move this stuff to `attach` and `detach` helpers as discussed?



src/slave/slave.cpp
Lines 9261 (patched)


Why are you doing the detach here? Detach should only happen when the 
executor run directory is gc'ed or if the task goes out of completed.


- Vinod Kone


On Jan. 14, 2018, 2:30 p.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/64978/
> ---
> 
> (Updated Jan. 14, 2018, 2:30 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Gilbert Song, Jie Yu, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-8279
> https://issues.apache.org/jira/browse/MESOS-8279
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> In MESOS-7225, we made a task can access any volumes specified in its
> disk resources from its own sandbox by introducing a workaround to the
> default executor, i.e., add a `SANDBOX_PATH` volume with type `PARENT`
> to the corresponding nested container. It will be translated into a bind
> mount in the nested container's mount namespace, thus not visible in the
> host mount namespace, that means the task's volume directory can not be
> visible in Mesos UI since it operates in the host mount namespace.
> 
> In this patch, to make the task's volume directory visible in Mesos UI,
> we attached the executor's volume directory to it, so when users browse
> task's volume directory in Mesos UI, what they actually browse is the
> executor's volume directory. Note when calling `Files::attach()`, the
> third argument `authorized` is not specified, that is because it is
> already specified when we do the attach for the executor's sandbox and
> it is also applied to the executor's tasks.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 
> 
> 
> Diff: https://reviews.apache.org/r/64978/diff/3/
> 
> 
> Testing
> ---
> 
> sudo make check
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 65156: Detached the virtual paths regardless of the result of gc.

[Vinod Kone]

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


Ship it!




Can you expand on the description on why this change is necessary?

- Vinod Kone


On Jan. 14, 2018, 2:17 p.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65156/
> ---
> 
> (Updated Jan. 14, 2018, 2:17 p.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-8444
> https://issues.apache.org/jira/browse/MESOS-8444
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Detached the virtual paths regardless of the result of gc.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 
> 
> 
> Diff: https://reviews.apache.org/r/65156/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 65156: Detached the virtual paths regardless of the result of gc.

[Mesos Reviewbot Windows]

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



PASS: Mesos patch 65156 was successfully built and tested.

Reviews applied: `['65156']`

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

- Mesos Reviewbot Windows


On Jan. 14, 2018, 2:17 p.m., Qian Zhang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65156/
> ---
> 
> (Updated Jan. 14, 2018, 2:17 p.m.)
> 
> 
> Review request for mesos and Vinod Kone.
> 
> 
> Bugs: MESOS-8444
> https://issues.apache.org/jira/browse/MESOS-8444
> 
> 
> Repository: mesos
> 
> 
> Description
> ---
> 
> Detached the virtual paths regardless of the result of gc.
> 
> 
> Diffs
> -
> 
>   src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 
> 
> 
> Diff: https://reviews.apache.org/r/65156/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Qian Zhang
> 
>

Re: Review Request 64978: Made task's volume directory visible in the /files endpoints.

[Qian Zhang]

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

(Updated Jan. 14, 2018, 10:30 p.m.)


Review request for mesos, Benjamin Mahler, Gilbert Song, Jie Yu, and Vinod Kone.


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


Repository: mesos


Description
---

In MESOS-7225, we made a task can access any volumes specified in its
disk resources from its own sandbox by introducing a workaround to the
default executor, i.e., add a `SANDBOX_PATH` volume with type `PARENT`
to the corresponding nested container. It will be translated into a bind
mount in the nested container's mount namespace, thus not visible in the
host mount namespace, that means the task's volume directory can not be
visible in Mesos UI since it operates in the host mount namespace.

In this patch, to make the task's volume directory visible in Mesos UI,
we attached the executor's volume directory to it, so when users browse
task's volume directory in Mesos UI, what they actually browse is the
executor's volume directory. Note when calling `Files::attach()`, the
third argument `authorized` is not specified, that is because it is
already specified when we do the attach for the executor's sandbox and
it is also applied to the executor's tasks.


Diffs
-

  src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 


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


Testing
---

sudo make check


Thanks,

Qian Zhang

Review Request 65156: Detached the virtual paths regardless of the result of gc.

[Qian Zhang]

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

Review request for mesos and Vinod Kone.


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


Repository: mesos


Description
---

Detached the virtual paths regardless of the result of gc.


Diffs
-

  src/slave/slave.cpp aeb0fdaeda78f26de2ec790735bfa88c5be72850 


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


Testing
---


Thanks,

Qian Zhang