inline below ----- Original Message -----
> From: "Tim Chen" <t...@mesosphere.io> > To: u...@mesos.apache.org > Cc: "dev" <dev@mesos.apache.org> > Sent: Wednesday, December 3, 2014 11:20:47 AM > Subject: Re: Rocket > Hi Tim, > I see you've already commented on the rocket repo about this, and from their > messaging it aims to be independent which should be the whole point of the > open container spec. I'm all over this like white on rice. > I think the best way is just to be involved in the spec early on and continue > to do so while we move forward, and we have relationships with the rocket > people which should help also being in the loop as well. Relationships alone won't cut it. Friends one day, enemies the next, isn't that the way it worked with Docker...? Governance, such as Apaches model, is of critical importance. > Tim > On Wed, Dec 3, 2014 at 8:26 AM, Tim St Clair < tstcl...@redhat.com > wrote: > > Not to put too fine a point on it, but how are folks planning on > > establishing > > governance around the App Container spec? > > > https://github.com/coreos/rocket/issues/193 > > > If the mesos community decides to leverage our own, how do we ensure that > > we > > have say in the spec going forwards? > > > Cheers, > > > Tim > > > ----- Original Message ----- > > > > From: "Tobias Knaup" < t...@knaup.me > > > > > To: u...@mesos.apache.org > > > > Cc: "dev" < dev@mesos.apache.org > > > > > Sent: Monday, December 1, 2014 11:39:58 PM > > > > Subject: Re: Rocket > > > > > > > > An important point to clarify is that two things were announced: a spec > > > > (App Container) and an implementation (Rocket). > > > > Here is the spec: > > > > https://github.com/coreos/rocket/blob/master/app-container/SPEC.md > > > > This separation of spec and implementation is important. It makes it much > > > > easier to integrate in Mesos. systemd is also just the implementation of > > > > the runtime part of the spec that CoreOS chose for Rocket. Mesos can use > > > > something else or come with its own. > > > > > > > > > > > > On Mon, Dec 1, 2014 at 1:29 PM, Dominic Hamon < dha...@twopensource.com > > > > > wrote: > > > > > > > > > Instead of considering the Rocket runtime as implemented, we should > > > > > instead consider how we can implement their specification. A community > > > > is > > > > > always healthier when there are multiple implementations of a > > > > > specification, and through implementing it we may find ways to improve > > > > it. > > > > > > > > > > Also, this allows us to be a strong voice in the community and provide > > > > > value through a C++ implementation. > > > > > > > > > > I've created a JIRA ticket > > > > > https://issues.apache.org/jira/browse/MESOS-2162 to track any thoughts > > > > on > > > > > this. > > > > > > > > > > On Mon, Dec 1, 2014 at 11:10 AM, Tim Chen < t...@mesosphere.io > wrote: > > > > > > > > > >> Hi all, > > > > >> > > > > >> Per the announcement from CoreOS about Rocket ( > > > > >> https://coreos.com/blog/rocket/ ) , it seems to be an exciting > > > > >> containerizer runtime that has composable isolation/components, better > > > > >> security and image specification/distribution. > > > > >> > > > > >> All of these design goals also fits very well into Mesos, where in > > > >> Mesos > > > > >> we also have a pluggable isolators model and have been experiencing > > > >> some > > > > >> pain points with our existing containerizers around image distribution > > > >> and > > > > >> security as well. > > > > >> > > > > >> I'd like to propose to integrate Rocket into Mesos with a new Rocket > > > > >> containerizer, where I can see we can potentially integrate our > > > >> existing > > > > >> isolators into Rocket runtime. > > > > >> > > > > >> Like to learn what you all think, > > > > >> > > > > >> Thanks! > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Dominic Hamon | @mrdo | Twitter > > > > > *There are no bad ideas; only good ideas that go horribly wrong.* > > > > > > > > > > > > -- > > > Cheers, > > > Timothy St. Clair > > > Red Hat Inc. > -- Cheers, Timothy St. Clair Red Hat Inc.
