I just spend the last hour or so digging through the code and playing with CLI. It's pretty neat. The "specification" for creating new containers (how to describe limits, namespacing etc) is not very well documented so it takes some trial and error... But this feels like a nice, clean low-level component.
It can be used as a C++ library, too - I'm going to evaluate it as a possible low-level execution backend for docker :)
In response to the other comments mentioning docker - this definitely does not compete with docker. A better comparison would be with the lxc tools or maybe something like libvirt-lxc or systemd's nspawn.
* Building is relatively straightforward on an Ubuntu system. You'll need to install re2 from source, but that's about it.
* No configuration necessary to start playing. lmctfy just straight up mounts cgroups and starts playing in there.
* Containers can be nested which is nice.
* I really couldn't figure out useful values for the container spec. Even the source doesn't seem to have a single reference - it's all dynamically registered by various subsystems in a rather opaque way. I opened a few issues to ask for more details.
* This is a really low-level tool. Other than manipulating cgroups it doesn't seem to do much, which is perfect for my particular use case (docker integration). I couldn't figure out how to set namespaces (including mnt and net namespaces which means all my containers shared the host's filesystem and network interfaces). I don't know if that functionality is already in the code, or has yet to be added.
* Given the fairly small footprint, limited feature set, and clean build experience, this really looks like an interesting option to use as a backend for docker. I like that it carries very little dependencies. Let's see what the verdict is on these missing features.
Most apps running on Google servers are aware that they're running in a shared environment, so they don't need the overhead of virtualized network interfaces. So I doubt that there will be any specific support for network namespaces.
And you can approximate mount namespaces with chroots and bind mounts. (In some ways that's better, since it's a bit easier for a process outside the container to interact with the container's filesystem).
Damn. This means it's much less useful to me (and 99% of applications outside of google). I guess I could combine lmctfy with a namespacing library of my own. But that's more extra work than I was anticipating.
I'm sure they do - but again google is probably holding a proprietary alternative to virtually every piece of software in the world :) Most of it is too tied to "the google way" to be useful to anybody else.
This is more true than the idea that there's a competitive advantage. We would love to open-source more of our stack (and are working towards it), but it's all very tied to the rest of our cluster environment. Piece by piece.
As an ex-googler I agree. Much if it just wouldn't be useful as is to most people as it's an environment that few match in load, resources, and diversity of services. Plus it's all integrated tightly across the board.
It can be used as a C++ library, too - I'm going to evaluate it as a possible low-level execution backend for docker :)