I appreciate the thoughtful email Tom! There's a bunch there so I've just made some inline comments addressing your final questions. ;-)
- Can the docker containerizer support more friendly defaults? If I only > want my mesos cluster to containerizer things with Docker, but don't wish > to require every user specify an image for their tasks. > Requiring a user to specify an image for their task/executor was indeed one of the biggest simplifying design decision we made for this first iteration of Docker in Mesos. There was some discussion on JIRA about this too. That all being said, I don't see any major blockers to introducing the idea of a "default image" for a task/executor that doesn't specify any details in ContainerInfo. I've had some chats with Ian Downes about doing something like this for the MesosContainerizer too (but using a tarball/zip or path that gets read-only bind-mounted into the container instead of a Docker image). If we don't already have a JIRA issue for this specific feature, we should add one so folks can follow along. - Since all of this Docker work has made it's way into the mesos core, a > lot of implicit decisions have been made about what options to support, how > to expose them to users, and how the workflow looks for frameworks and > users. I think this is pretty limiting, and given Mesos is designed to be > the fundamental building blocks for your datacenter, building for specific > workflows concerns me. Is finding solutions to all of these workflows > really something the mesos-core team should focus on? > The explicit limiting was done because we wanted to abstract ourselves away from the Docker CLI (as you mentioned earlier) and this is just the first iteration. Tim Chen is already working on the second iteration which includes things like bridge networking. Even so, we're really trying to abstract ourselves as much as possible since even Docker itself is being decomposed into libcontainer (and maybe more?) and we'd really like to consolidate our own internal containerizers/isolation code with libcontainer. That consolidation will likely be a long process, but it's well worth it in the long run IMHO. Regarding workflows, I still think the external containerizer is the best bet to capture an organization specific workflow. As you mention below, this is a huge asset to Mesos and something I'd personally like to make sure continues to work well, as would Till Toenshoff I'm sure. If you have other suggestions for how to more generically support workflows we'd love to hear them! - I think the external containerizer is a value asset to Mesos even without > Docker. There have been a few questions on the mailing list about using > other types of isolation (on windows for example). Could more work be done > to unity configuration for each built-in containerizer? I feel like lots of > different command line options might be a little confusing over time. > Can you elaborate on what you mean when you say "unity configuration"? If you're referring to command line flags, I'd love to hear your suggestions. If you're referring to broader support for sharing components between containerizers, I agree wholeheartedly. In fact, while the containerizer/isolator part of the code base has seen quite a bit of volatility in the last year I think it's due in for even more going forward. Ultimately I'd like to see us reusing our existing isolators with something like the Docker containerizer (and other containerizers) so that folks can benefit from the isolation work that's being done irregardless of how the container gets initially created! And as I mentioned above, it might make sense to directly consume libcontainer here too, possibly even contributing some of our isolators to it. Ben.
