[
https://issues.apache.org/jira/browse/MESOS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083043#comment-14083043
]
Vinod Kone commented on MESOS-1659:
-----------------------------------
But this assumes that libmesos built for host OS is compatible with the OS of
the docker container, which might not be true. Also, libmesos itself has shared
deps which should also be copied or visible from the docker 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)
