Mailing-List: contact dev-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
From: meghdoot_b@yahoo.com.INVALID
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Unified container support in Aurora
Message-Id: <887638E9-B6CA-4C99-8EAD-84D0FA0FE2DA@yahoo.com>
Date: Wed, 21 Oct 2015 23:02:37 -0700
References: 
 <CAOTkfX5m6Vs50NiR+MbJHqgHwaW81x13UYsusqSoc1OhJet8Cg@mail.gmail.com>
 <1445414309661.77792@blue-yonder.com>
 <CAK7Zj12KiUG7X4=+3SsZV=16UnjasjiwWwxryjf9=EvB3eVcjw@mail.gmail.com>
 <CAJ4qn4kwC4EHWK6FebSbcR=M4HN=iSbE=O2pETdsZmEh2v8bow@mail.gmail.com>
 <CAJvN1BMvUHuNZ2v0Tt20kbjx9hi_CZ0vSKGSw=hL8o1Wxd9s4A@mail.gmail.com>
In-Reply-To: 
 <CAJvN1BMvUHuNZ2v0Tt20kbjx9hi_CZ0vSKGSw=hL8o1Wxd9s4A@mail.gmail.com>
To: "dev@aurora.apache.org" <dev@aurora.apache.org>

Is the file system isolation going to provide aufs/overlayfs etc kind of dri=
vers to store the layers to Steve's point with COW because that is a key par=
t 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 a=
s 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 generi=
c which is great but in the end there would be folks who will still prefer t=
o run docker with the daemon and with docker's network and volume plugins ra=
ther 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 j=
ust 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 t=
hat point what one may not want different run times in different environment=
 (dev vs prod).

Thx

Sent from my iPhone

> On Oct 21, 2015, at 2:52 PM, Jie Yu <yujie.jay@gmail.com> wrote:
>=20
> Steve,
>=20
> 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
> <https://www.opencontainers.org/>that the community is working on will
> separate runtime isolation from image format as well.
>=20
> Regarding your questions:
>=20
> Lack of support for a docker registry removes one of the two biggest
>=20
> reasons for using docker.  (You don't have to worry about distribution)
>=20
>=20
> 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 <https://issues.apache.org/jira/browse/MESOS-3166>), and will b=
e
> ready soon.
>=20
> I'm unclear how they plan to support non-filesystem layers, such as ENV
>=20
> directives in the docker containers.
>=20
>=20
> Mesos already allow framework to specify environment variables for
> executors/tasks (see here
> <https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L39=
5>).
> What's your concern?
>=20
> - Jie
>=20
> On Wed, Oct 21, 2015 at 2:13 PM, Steve Niemitz <sniemitz@twitter.com.inval=
id
>> wrote:
>=20
>> 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.
>>=20
>> - 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.
>>=20
>> 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 laye=
rs
>> is unacceptable), I don't see their docker support being very useful.
>>=20
>>> On Wed, Oct 21, 2015 at 4:59 PM, Zameer Manji <zmanji@apache.org> wrote:=

>>>=20
>>> I'm in favor of eventually deprecating the existing Docker implementatio=
n
>>> 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.
>>>=20
>>> On Wed, Oct 21, 2015 at 12:58 AM, Erb, Stephan <
>>> Stephan.Erb@blue-yonder.com>
>>> wrote:
>>>=20
>>>> Hi Maxim,
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Best Regards,
>>>> Stephan
>>>> ________________________________________
>>>> From: Maxim Khutornenko <maxim@apache.org>
>>>> Sent: Tuesday, October 20, 2015 11:23 PM
>>>> To: dev@aurora.apache.org
>>>> Subject: Unified container support in Aurora
>>>>=20
>>>> With Mesos community closing in on the unified container solution
>>>> (MESOS-2386)[1], what is our stance on supporting it in Aurora?
>>>>=20
>>>> 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.
>>>>=20
>>>> 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?
>>>>=20
>>>> Thanks,
>>>> Maxim
>>>>=20
>>>> [1] -
>> https://docs.google.com/document/d/1Fx5TS0LytV7u5MZExQS0-g-gScX2yKCKQg9UP=
Fzhp6U
>>>> [2] -
>> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d001150172242=
84a1/include/mesos/mesos.proto#L1416
>>>> [3] -
>> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d001150172242=
84a1/include/mesos/mesos.proto#L1296
>>>>=20
>>>> --
>>>> Zameer Manji
>>>>=20
>>>>=20
>>>> <
>> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d001150172242=
84a1/include/mesos/mesos.proto#L1296
>>=20