aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jie Yu <yujie....@gmail.com>
Subject Re: Unified container support in Aurora
Date Wed, 21 Oct 2015 21:52:42 GMT
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