Hacker News Reader

Comment by shykes | Hacker News Reader

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.

View on HN

Quick summary of my early explorations:

* 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.

> useful values for the container spec

Are you referring to the container spec in the proto file? https://github.com/google/lmctfy/blob/master/include/lmctfy.... Which attributes are you having trouble setting a useful value for?

Thank you! I was scanning .h files for a type declaration.. Silly old-school me :)

I only knew because I've worked with the internal analogue of this library recently. Glad I could help.

According to the docs all that can be set is cpu and memory limits. So maybe that's the extent of it for now, even though the proto identifies more.

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.

Namespaces will be coming, but we're not there yet. This captures some of what we are already doing internally, but not all of it, yet.

The namespacing part is much simpler, if you have specific use cases.

Perhaps they'd be open to a collaboration where you add that functionality and then you use it to make docker (even more!) awesome.

We (lmctfy team) are in the middle of designing and adding namespace support. It will start trickling in soon.

google is probably holding the piece that competes with docker or openvz, they should have somthing like docker internally

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.

Reply on news.ycombinator.com