> On March 11, 2017, 4:28 a.m., Stephan Erb wrote: > > I need a little bit more context to understand what is going on here: > > > > * Do you plan to use this with Thermos or an alternative executor? Or both? > > * It seems like we don't need this for Thermos as we already create > > mountpoints when needed (see do_mount() in > > aurora/executor/common/sandbox.py) > > * Switching the flag will run the executor within the filesystem image and > > thus require Python and all libmesos dependencies within the image. This > > sounds like a big downfall just for gaining the mkdir. > > Joshua Cohen wrote: > +1, it's unclear to me why this is necessary. If it is, I'd consider it a > bug in the sandbox code that prepares mounts. It should be making any > directories that don't already exist under taskfs: > > > # If we're mounting a file into the task filesystem, the mount call > will fail if the mount > # point doesn't exist. In that case we'll create an empty file to > mount over. > if os.path.isfile(source) and not os.path.exists(destination): > safe_mkdir(os.path.dirname(destination)) > touch(destination) > else: > safe_mkdir(destination) > > > https://github.com/apache/aurora/blob/master/src/main/python/apache/aurora/executor/common/sandbox.py#L284-L290 > > Zameer Manji wrote: > I see that I have been unclear here. I will take some time to better > document the problem to explain why I think this is necesssary. > > Zameer Manji wrote: > Ok, after some thought and understanding here are my reasons for this > patch: > > * This method allows operators to use a cluster with other executors that > are not Thermos and are statically linked binaries that can be run in any FS > image. > * This allows to use other executors (or the Command Executor) that do > not have the code to do the mount preperation and `chroot`. This allows for > uniformity in a cluster that has multiple frameworks. By having consistently > constructed containers, this means tooling can ineract with the container in > a uniform manner (ie `mesos-cli` or `nsneter`). > * There are some drawbacks in the method thermos uses, including exposing > the host filesystem to privlidged users in the task. For example, if I launch > a task with the MesosContainerizer with pid isolation and fs isolation in > vagrant and use nsenter to enter the namespace of of the task, I still have > access to the host namespace. > > Inside the filesystem: > ``` > root@aurora:/# ps auxf > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 160 0.0 0.0 20252 2068 ? S 06:56 0:00 -bash > root 188 0.0 0.0 17488 1148 ? R+ 06:57 0:00 _ ps > auxf > root 1 0.0 0.6 163396 19680 ? Ss 06:52 0:00 > mesos-containerizer launch > --command={"shell":true,"value":"${MESOS_SANDBOX=.}\/thermos_executor.pex > --announcer-en > root 8 0.0 0.0 4440 648 ? S 06:52 0:00 sh -c > ${MESOS_SANDBOX=.}/thermos_executor.pex --announcer-ensemble localhost:2181 > --announcer-zookeeper-auth-config > root 9 0.6 1.3 1075684 42512 ? Sl 06:52 0:01 _ > python2.7 > /var/lib/mesos/slaves/5d33ec50-e419-4df8-9640-5680fd0921d1-S0/frameworks/5d33ec50-e419-4df8-9640-5680 > root 34 0.2 0.7 77712 23416 ? S 06:52 0:00 _ > /usr/bin/python2.7 > /var/lib/mesos/slaves/5d33ec50-e419-4df8-9640-5680fd0921d1-S0/frameworks/5d33ec50-e419-4 > www-data 39 0.0 0.6 75652 21200 ? Ss 06:52 0:00 > _ /usr/bin/python2.7 > /var/lib/mesos/slaves/5d33ec50-e419-4df8-9640-5680fd0921d1-S0/frameworks/5d33ec50-e4 > www-data 41 0.0 0.0 20040 1496 ? S 06:52 0:00 > _ /bin/bash -c while true; do echo hello world sleep 10 > done > www-data 187 0.0 0.0 4228 348 ? S 06:57 0:00 > _ sleep 10 > root@aurora:/# cat /etc/issue > Debian GNU/Linux 8 \n \l > root@aurora:/# cat /proc/1/root/etc/issue > Ubuntu 14.04.5 LTS \n \l > ``` > > I feel the original goal is noble, but creates a lot of complexity for > operators, tools, cluster operators and it "goes against the grain" of what > the Mesos API is requesting frameworks to do. > > I feel this flag has minimal (no?) negative effects, and enhances the > utility of the scheduler. > > Stephan Erb wrote: > I feel a little bit uneasy about the explosion of mode flags on Thermos > (e.g see AURORA-1909 for the consequences). Do you think the new POD API help > us to solve the problem in a more robust and general way?
The pod API could help us, but it would require changing thermos in a huge way. Plus this is still not custom executor friendly. > On March 11, 2017, 4:28 a.m., Stephan Erb wrote: > > src/main/java/org/apache/aurora/scheduler/configuration/executor/ExecutorModule.java > > Lines 108-111 (patched) > > <https://reviews.apache.org/r/57524/diff/1/?file=1661884#file1661884line108> > > > > If the need for the flag is executor specific, it will make sense to > > move this to the executor config rather than maintain it as a global toggle. > > > > > > We should probably: > > > > * add this to the changelog > > * mention and explain this in either > > https://github.com/apache/aurora/blob/master/docs/features/containers.md#mesos-containerizer > > or > > https://github.com/apache/aurora/blob/master/docs/features/custom-executors.md > > Zameer Manji wrote: > Should my reasoning above be accepted, I will make these changes. serb: Do you accept my reasoning above? If so I can make these changes. - Zameer ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57524/#review168709 ----------------------------------------------------------- On March 13, 2017, 9:36 a.m., Zameer Manji wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/57524/ > ----------------------------------------------------------- > > (Updated March 13, 2017, 9:36 a.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 > >
