[
https://issues.apache.org/jira/browse/MESOS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083158#comment-14083158
]
Jay Buffington commented on MESOS-1659:
---------------------------------------
[~dhamon] kernels inside a container are not booted. Containers (well,
namespaces) are created by a clone or unshare system call, so the kernel is
always the same inside and outside the container because there is only one
kernel. I suggest either requiring a statically built libmesos or recursively
bringing in all deps and using LD_LIBRARY_PATH exactly because we can't rely on
anything inside the container.
> 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)
