[
https://issues.apache.org/jira/browse/MESOS-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083911#comment-14083911
]
Timothy Chen commented on MESOS-1659:
-------------------------------------
[~jaybuff] also I think once we start seeing how everyone is using the Docker /
Mesos integration, and if a majority of use cases and folks are looking for
this then we can definitely consider it again as this is an add-on. What you
think?
> 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)
