aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Unified container support in Aurora
Date Thu, 22 Oct 2015 06:02:37 GMT
Is the file system isolation going to provide aufs/overlayfs etc kind of drivers to store the
layers to Steve's point with COW because that is a key part of docker performance?

Also docker has started to support cgroup parents flag (has some issues) but once fixed can
be used to form a cgroups hierarchy with mesos task cgroup as parent of docker container.
So, shouldn't be incompatible I would think.

I think it's all about choice. Mesos is positioning itself to be more generic which is great
but in the end there would be folks who will still prefer to run docker with the daemon and
with docker's network and volume plugins rather than mesos storage and network solves. Similar
case for rkt.

It's good to be OCI compliant from runtime but one needs richer tools than just runtime support.
Just compare runC and docker commands and one would see the difference. So there is a place
for these tools beyond runtime and at that point what one may not want different run times
in different environment (dev vs prod).


Sent from my iPhone

> On Oct 21, 2015, at 2:52 PM, Jie Yu <> wrote:
> Steve,
> The motivation for unified container support in Mesos is to support docker
> image format without relying on docker runtime (i.e., docker daemon),
> because docker's runtime isolation (e.g., cpu, memory, etc) is not
> compatible with Mesos's runtime isolation. The open container initiative
> <>that the community is working on will
> separate runtime isolation from image format as well.
> Regarding your questions:
> Lack of support for a docker registry removes one of the two biggest
> reasons for using docker.  (You don't have to worry about distribution)
> What do you mean? Are you saying that Mesos does not maintain a docker
> registry? Or Mesos does not have a way to pull docker images from a docker
> registry? For the latter, it is being actively worked on in Mesos (
> MESOS-3166 <>), and will be
> ready soon.
> I'm unclear how they plan to support non-filesystem layers, such as ENV
> directives in the docker containers.
> Mesos already allow framework to specify environment variables for
> executors/tasks (see here
> <>).
> What's your concern?
> - Jie
> On Wed, Oct 21, 2015 at 2:13 PM, Steve Niemitz <
>> wrote:
>> I think the unified container support will eventually be superior to the
>> current docker implementation, however after reading over the design doc, a
>> few critical pieces are missing that makes it basically a non starter for
>> now.
>> - Lack of support for a docker registry removes one of the two biggest
>> reasons for using docker.  (You don't have to worry about distribution)
>> - I'm unclear how they plan to support non-filesystem layers, such as ENV
>> directives in the docker containers.
>> As-is, they're not really actually providing support for docker, simply
>> support for the container format.  Until mesos can actually pull from a
>> repo and supports a better provisioning strategy (simply copying the layers
>> is unacceptable), I don't see their docker support being very useful.
>>> On Wed, Oct 21, 2015 at 4:59 PM, Zameer Manji <> wrote:
>>> I'm in favor of eventually deprecating the existing Docker implementation
>>> and moving to Mesos unified container support. The issues with the
>> existing
>>> Docker integration (including MESOS-1659) makes me think that we should
>>> adopt something that is better integrated with the Mesos model. I'd be
>>> curious to see what others think about this.
>>> On Wed, Oct 21, 2015 at 12:58 AM, Erb, Stephan <
>>> wrote:
>>>> Hi Maxim,
>>>> we would be interested in the unified container support as well. It
>> would
>>>> allow us to independently update the major version of the slave OS and
>>> the
>>>> OS used within containers.
>>>> Nevertheless, while very interesting for the future, it is not a
>> pressing
>>>> issue for us right now. In addition, as we are not using docker,
>> backward
>>>> compatibility is not a blocker for us.
>>>> Best Regards,
>>>> Stephan
>>>> ________________________________________
>>>> From: Maxim Khutornenko <>
>>>> Sent: Tuesday, October 20, 2015 11:23 PM
>>>> To:
>>>> Subject: Unified container support in Aurora
>>>> With Mesos community closing in on the unified container solution
>>>> (MESOS-2386)[1], what is our stance on supporting it in Aurora?
>>>> The current Docker integration in Aurora predates this effort and
>>>> relies on ContainerInfo.Type.DOCKER (2) (eventually to be deprecated?)
>>>> rather than the newly introduced Image.DOCKER (3) spec. More
>>>> importantly though, the shift to the image-based spec and the unified
>>>> Mesos containerizer will finally allow us to support multiple
>>>> container types (Docker, AppC) and run executor outside of a task
>>>> image space. The latter, IMO, will be a huge win for us as baking
>>>> python-based-native-lib-dependent executor into a customer image was
>>>> less than ideal to start with (e.g. MESOS-1659) and one of the reasons
>>>> current Docker support in Aurora is still in beta.
>>>> I propose we freeze and eventually deprecate the existing Docker
>>>> implementation in Aurora in favor of the new approach (to be designed)
>>>> leveraging the Mesos unified container support. Thoughts?
>>>> Thanks,
>>>> Maxim
>>>> [1] -
>>>> [2] -
>>>> [3] -
>>>> --
>>>> Zameer Manji
>>>> <

View raw message