You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Tom Arnfeld (JIRA)" <ji...@apache.org> on 2014/06/21 11:14:25 UTC

[jira] [Comment Edited] (MESOS-1524) Implement Docker support in Mesos

    [ https://issues.apache.org/jira/browse/MESOS-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039739#comment-14039739 ] 

Tom Arnfeld edited comment on MESOS-1524 at 6/21/14 9:13 AM:
-------------------------------------------------------------

This sounds really great. I think implementing this would be easier now since the refactor of the Containerizer classes...?

I'd vote for #2 since i'd guess it's easier (than #3) to support launching containers on a remote host (the {{-H}} argument in #1). This is really quite useful for development, when running Mesos on a Mac and having docker running inside VM, for example.

For me though, this does raise a question. From what I gathered the main idea behind the external containerizer was to allow not just pluggability (the c++ classes _could_ be made "pluggable") but also ease of use for developers and users to get involved. How do you envisage this happening with other isolation mechanisms? Will the external containerizer act as a way of proving the concept, and eventually support for that containerizer would be implemented into Mesos itself? Especially given the design of the current external containerizer is aimed at supporting multiple types of containers in one slave (with the {{docker:///}} scheme), in the future.


was (Author: tarnfeld):
This sounds really great. I think implementing this would be easier now since the refactor of the Containerizer classes...?

I'd vote for #2 since i'd guess it's easier (than #3) to support launching containers on a remote host (the {{-H}} argument in #1). This is really quite useful for development, when running Mesos on a Mac and having docker running inside VM, for example.

For me though, this does raise a question. From what I gathered the main idea behind the external containerizer was to allow not just pluggability (the c++ classes _could_ be made "pluggable") but also ease of use for developers and users to get involved. How do you envisage this happening with other isolation mechanisms? Will the external containerizer act as a way of proving the concept, and eventually support for that containerizer would be implemented into Mesos itself? Especially given the design of the current external containerizer is aimed at support multiple types of containers in one slave (with the {{docker:///}} scheme).

> Implement Docker support in Mesos
> ---------------------------------
>
>                 Key: MESOS-1524
>                 URL: https://issues.apache.org/jira/browse/MESOS-1524
>             Project: Mesos
>          Issue Type: Epic
>            Reporter: Tobi Knaup
>            Assignee: Benjamin Hindman
>
> There have been two projects to add Docker support to Mesos, first via an executor, and more recently via an external containerizer written in Python - Deimos: https://github.com/mesosphere/deimos
> We've got a lot of feedback from folks who use Docker and Mesos, and the main wish was to make Docker a first class citizen in Mesos instead of a plugin that needs to be installed separately. Mesos has been using Linux containers for a long time, first via LXC, then via cgroups, and now also via the external containerizer. For a long time it wasn't clear what the winning technology would be, but with Docker becoming the de-facto standard for handling containers I think Mesos should make it a first class citizen and part of core.
> Let's use this JIRA to track wishes/feedback on the implementation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)