> 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.
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.
- 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
>
>
