aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Niemitz <sniem...@twitter.com.INVALID>
Subject Re: Unified container support in Aurora
Date Thu, 22 Oct 2015 14:46:36 GMT
>
> because docker's runtime isolation (e.g., cpu, memory, etc) is not
> compatible with Mesos's runtime isolation


I find that kind of an odd statement, as they both just use cgroups to
achieve said isolation.


> 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
> be
> ready soon.


The latter, I was only commenting based on what was in the design doc
linked above, if support for pulling images from a repo is already in the
works, thats great, although unfortunately I can't look at the design doc
linked in the ticket (it's not publicly viewable).

Mesos already allow framework to specify environment variables for
> executors/tasks (see here ...) What's your concern?


The concern is that this is presented as "docker support", but isn't
really.  Saying that mesos has "docker support" would lead me to believe
that I can run a docker container in mesos's unified container system and
it'd perform exactly like it would in the docker daemon (as I can today).
Without supporting things like ENV in layers, that parity is lost.

Ultimately, without things like repo support (in progress?), aufs, and ENV
variables, the utility of this new unified container system seems severely
lacking, especially compared to the current state of docker support in
mesos today.

On Wed, Oct 21, 2015 at 5:52 PM, Jie Yu <yujie.jay@gmail.com> 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
> <https://www.opencontainers.org/>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 <https://issues.apache.org/jira/browse/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
> <
> https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L395
> >).
> What's your concern?
>
> - Jie
>
> On Wed, Oct 21, 2015 at 2:13 PM, Steve Niemitz
> <sniemitz@twitter.com.invalid
> > 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 <zmanji@apache.org> 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 <
> > > Stephan.Erb@blue-yonder.com>
> > > 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 <maxim@apache.org>
> > > > Sent: Tuesday, October 20, 2015 11:23 PM
> > > > To: dev@aurora.apache.org
> > > > 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] -
> > > >
> > >
> >
> https://docs.google.com/document/d/1Fx5TS0LytV7u5MZExQS0-g-gScX2yKCKQg9UPFzhp6U
> > > > [2] -
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d00115017224284a1/include/mesos/mesos.proto#L1416
> > > > [3] -
> > > >
> > >
> >
> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d00115017224284a1/include/mesos/mesos.proto#L1296
> > > >
> > > > --
> > > > Zameer Manji
> > > >
> > > >
> > > > <
> > >
> >
> https://github.com/apache/mesos/blob/3c35a6b20dc07228ca30ad2d00115017224284a1/include/mesos/mesos.proto#L1296
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message