> On March 11, 2016, 1:36 a.m., Joshua Cohen wrote: > > Given the proposal to move towards the Mesos unified containerizer, do you > > think it makes sense to hold off on this and instead implement it in > > conjunction with those upcoming changes? > > > > I haven't gotten any direct feedback on the dev thread, but via IRC people > > generally seem in favor. If there are no blockers, I can start working on > > that support next week (we can even divy up the work if you've got cycles > > ;)). > > Bill Farner wrote: > Given the relatively small ripple here, i would personally prefer to > proceed with the patch and revert in the future if alternative support proves > superior. Scanning tickets in the mesos queue, looks like there's still a > decent chunk of work for this alternative support to catch up with the > existing route. > > In the broader context, i'm not a huge fan of the direction mesos is > headed here. It's going to require continued effort to maintain > compatibility with Docker features, which i think ultimately hurts the user. > I'm generally in favor of more choices -- i think the unified containerizer > support represents a choice, and stock Docker support represents another.
I had been working under the assumption that our goal was to deprecate and remove the current Docker support in favor of the unified containerizer support once it was available. Given that, it doesn't seem worthwhile to invest too heavily in the current DockerContainerizer based support. It seems that you disagree (which is perfectly valid, of course) with that approach. Can you comment on the proposal with your concerns? I'd like to start working on it soon, but there's clearly at least still something of a gap in terms of vision on this. - Joshua ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44685/#review123059 ----------------------------------------------------------- On March 11, 2016, 2:24 a.m., Bill Farner wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44685/ > ----------------------------------------------------------- > > (Updated March 11, 2016, 2:24 a.m.) > > > Review request for Aurora, Joshua Cohen and John Sirois. > > > Repository: aurora > > > Description > ------- > > This is currently labeled as experimental. > > Only the most basic wiring is added here, and assumes that the provided image > includes an ENTRYPOINT. Unlike Docker support via the thermos executor, this > approach allows containers with an entrypoint, and does not impose environment > requirements on the image (e.g. python interpreter, libmesos dependencies). > > Note that when using this, other familiar Aurora facilities that relate to the > thermos executor will not work. For example, browsing task logs is not > supported. > > Support for exercising this from the client will come shortly. > > > Diffs > ----- > > NEWS da3e4cea8ca688b6b7c5bafae67133df065d9255 > src/jmh/java/org/apache/aurora/benchmark/ThriftApiBenchmarks.java > 60746383fccb107ca27925a91aa1803e2cf0fd85 > src/main/java/org/apache/aurora/scheduler/app/AppModule.java > a0d2a717534bbb2e85a556721cc53c1e4b743461 > src/main/java/org/apache/aurora/scheduler/base/TaskTestUtil.java > 1de6966565d2fbd9abd220ad8162b624b109959a > > src/main/java/org/apache/aurora/scheduler/configuration/ConfigurationManager.java > e700fa3550312bfa9c8a3adb25d135f6f500c4b5 > src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java > a34af4d2fb3863ab8197bcdce942c513d629621b > > src/test/java/org/apache/aurora/scheduler/configuration/ConfigurationManagerTest.java > 11062e3a097e490c61bfd4dc84990903275521a3 > > src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java > 3db531b52fb2bd94b4b5ce62e6554b5a85ed3ea8 > > Diff: https://reviews.apache.org/r/44685/diff/ > > > Testing > ------- > > Via additional hacking, i successfully ran the stock [hello > world](https://hub.docker.com/_/hello-world/) image. Within the sandbox, i > observed the expected output in the `stdout` file. Status updates for the > task exiting worked as expected. > > > Thanks, > > Bill Farner > >
