> On June 8, 2017, 4:07 p.m., Stephan Erb wrote: > > Thanks for the nudge, sorry for the epic delay. > > > > I agree that it is valuable to have a mode that runs Aurora containers > > similar to other Mesos containers (as least until we support PODs). I am > > therefore OK with the direction and goal of this patch. Turns out, I also > > have a potential usecase for this: Use the Mesos agent > > `--default_container_info` option to inject each task into a container > > without having to adjust all tasks on the Aurora side. > > > > > > Looking at the patch though, I am confused if it works as is. Please > > correct me if I am wrong: > > > > * > > https://github.com/apache/aurora/blob/c85bffdd6f68312261697eee868d57069adda434/src/main/python/apache/aurora/executor/common/sandbox.py#L84 > > implies we will run Thermos using the `FileSystemImageSandbox` . > > * The `FileSystemImageSandbox` will instruct Thermos to call the > > containerizer again, even though Thermos itself will already be running > > within a container. > > https://github.com/apache/aurora/blob/c85bffdd6f68312261697eee868d57069adda434/src/main/python/apache/aurora/executor/thermos_task_runner.py#L265 > > * The `FileSystemImageSandbox` is also re-mounting volumes and could thus > > lead to problems as those will already be mounted by the outside > > containerizer call. > > https://github.com/apache/aurora/blob/c85bffdd6f68312261697eee868d57069adda434/src/main/python/apache/aurora/executor/common/sandbox.py#L302 > > Jason Lai wrote: > Hi Stephan! Thank you very much for the reply, particularly on pointing > out Thermos executor's use of > [`FileSystemImageSandbox`](https://github.com/apache/aurora/blob/c85bffdd6f68312261697eee868d57069adda434/src/main/python/apache/aurora/executor/common/sandbox.py#L84) > when running inside of a Mesos container. In this case, I believe we need > another patch to the executor in addition to this one, for surpressing the > use of `FileSystemImageSandbox` in favor of `DockerDirectorySandbox` when the > scheduler is configured to launch containers with their own root FS'es, in > order to make this patch fully working. > > I'm thinking about adding an extra executor command line argument > (`--image-root-fs`, default to `False`) to Thermos executor, so that when > `True`, `DockerDirectorySandbox` will be used instead. > > I also evaluated the impact of using `DockerDirectorySandbox` on health > checkers. It seems that with an instance with `#is_filesystem_image` as > `False`, the health checker will not be wrapped with `mesos-containerizer > launch` and will thus perform correctly. So this overall looks like a viable > approach. What do you think?
Please feel free to purpose a good name for the extra executor command line argument, if `--image-root-fs` doesn't ring a bell to you. I was also thinking about introducing `--no-mesos-containerizer-path` to set `mesos_containerizer_path` option to `None`, as the main purpose of this option is intended for collaborating in the scenario of `FileSystemImageSandbox`. Please let me know what you think. Thanks a lot! - Jason ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57524/#review177316 ----------------------------------------------------------- On March 13, 2017, 4:36 p.m., Zameer Manji wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57524/ > ----------------------------------------------------------- > > (Updated March 13, 2017, 4:36 p.m.) > > > Review request for Aurora, Santhosh Kumar Shanmugham and Stephan Erb. > > > Bugs: AURORA-1903 > https://issues.apache.org/jira/browse/AURORA-1903 > > > Repository: aurora > > > Description > ------- > > The mesos unified containerizer does not support absolute container path > mounts if no rootfs is set. This allows operators to switch between our > current behaviour (mounting images as a volume) and setting the rootfs. See > AURORA-1903 for more detailed analysis. > > > Diffs > ----- > > src/main/java/org/apache/aurora/scheduler/base/TaskTestUtil.java > f0b148cd158d61cd89cc51dca9f3fa4c6feb1b49 > > src/main/java/org/apache/aurora/scheduler/configuration/executor/ExecutorModule.java > 4dac9757a65e144142d36ee921b85a02a5311fe5 > > src/main/java/org/apache/aurora/scheduler/configuration/executor/ExecutorSettings.java > 5c987fd051728486172c8afd34219e86d56f00d5 > src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java > 0d639f66db456858278b0485c91c40975c3b45ac > src/main/java/org/apache/aurora/scheduler/mesos/TestExecutorSettings.java > e1cd81e6fbd98f23046e6e775be268be4310c62a > > src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java > 93cc34cf8393f969087cd0fd6f577228c00170e9 > > > Diff: https://reviews.apache.org/r/57524/diff/1/ > > > Testing > ------- > > > Thanks, > > Zameer Manji > >
