This is an automatically generated e-mail. To reply, visit:
(Updated July 26, 2016, 4:57 p.m.)
Review request for Aurora, Jie Yu, Maxim Khutornenko, and Stephan Erb.
Update to use new mesos-containerizer launch command to isolate the task's
filesystem rather than replicating all of that logic from Mesos into Thermos.
A couple of notes:
1) this depends on Mesos 1.0.0, so I won't ship this until that has shipped and
we've upgraded Aurora to depend on it.
2) End to end tests are failing for the GPU job which I'm assuming is related
to the fact that I've upgraded my vagrant image to Mesos 1.0.0 but have not
This changes the approach to launching tasks with filesystem images in the
unified containerizer. Instead of adding an `Image` to the `MesosContainer`, we
instead add the task filesystem as a `Volume` with an associated image. This
image is mounted in the mesos directory under the `taskfs` path. The executor,
on start up does the following:
1. Creates user/group under the taskfs root.
2. `pivot_root`s into the taskfs, while bind mounting the sandbox under that
root as well as mounting procfs.
3. From there, task execution is essentially unchanged minus some slight
changes to the environment depending on whether we're running in a pivoted root.
Lots of manual testing, e2e tests, etc.
I didn't add much coverage on the thermos side of things because it seemed like
this was better served by the e2e tests than by doing a bunch of
subprocess.check_call mocking. On the e2e front I created a new Dockerfile that
sets up a much slimmer filesystem image that explicitly does not include python
to ensure that the executor's filesystem is truly isolated.