[
https://issues.apache.org/jira/browse/MESOS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083068#comment-14083068
]
Dominic Hamon commented on MESOS-1659:
--------------------------------------
[~jaybuff] How is it guaranteed? There's nothing to stop me creating a docker
image with a new kernel as one of the layers. I can do the same for the OS too,
so although the architecture will be the same, the kernel and OS (and installed
packages) certainly won't necessarily be.
> docker containerizer should not require executor be part of image
> -----------------------------------------------------------------
>
> Key: MESOS-1659
> URL: https://issues.apache.org/jira/browse/MESOS-1659
> Project: Mesos
> Issue Type: Improvement
> Reporter: Jay Buffington
>
> I would like the ability to run an executor inside of an off-the-shelf docker
> container.
> We already have a process for getting an executor into the sandbox. I've
> spoken with [~tnachen] about this and we agreed that the containerize should
> bind mount (via the docker volumes feature) the sandbox into the container
> and run the executor.
> The problem with this is the majority of executors have a dependency on
> libmesos and libmesos usually doesn't exist in off the shelf containers.
> I propose the docker containerize also bind mount libmesos and it's
> dependencies (like libunwind) into the container and use LD_LIBRARY_PATH so
> the executor can find them.
> You could make an argument that executors should be statically compiled self
> contained binaries, but that is difficult with executors written in python or
> java. We can use pex or jar to package up language dependencies, but native
> deps like libmesos are tricky. Having the docker containerize guarantee that
> libmesos is there really simplifies things.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
