> On Jan. 9, 2018, 8:04 a.m., Vinod Kone wrote: > > Can you add a test or update an existing test to verify the /files endpoint > > for task volume? Ideally, you could also verify that once the executor's > > work directory is gc'ed the files endpoint no longer serves the task volume > > directory to ensure we are not leaking those directories. > > Qian Zhang wrote: > Sure, just posted a patch for test: https://reviews.apache.org/r/65070/
> you could also verify that once the executor's work directory is gc'ed the > files endpoint no longer serves the task volume directory to ensure we are > not leaking those directories. I am not sure how we can verify that. Did you mean accessing the task volume directory from `/files` endpoint again when the executor's work directory is gc'ed? But if the executor's work directory is gc'ed, certainly we will not be able to accessing the task volume directory from `/files` endpoint even it is not detached, failed to access task volume directory from `/files` endpoint does not mean it has been detached. - 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 > >
