5 ms·

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 som

by shykes 13y ago

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.

shykes 13y ago
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.
- jamesaguilar 13y ago
  > 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.proto https://github.com/google/lmctfy/blob/master/include/lmctfy.... Which attributes are you having trouble setting a useful value for?
  - shykes 13y ago
    Thank you! I was scanning .h files for a type declaration.. Silly old-school me :)
    - jamesaguilar 13y ago
      I only knew because I've worked with the internal analogue of this library recently. Glad I could help.
  - nickstinemates 13y ago
    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.
- menage 13y ago
  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).
  - shykes 13y ago
    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.
    - thockin 13y ago
      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.
    - justincormack 13y ago
      The namespacing part is much simpler, if you have specific use cases.
    - SEJeff 13y ago
      Perhaps they'd be open to a collaboration where you add that functionality and then you use it to make docker (even more!) awesome.
  - jnagal 13y ago
    We (lmctfy team) are in the middle of designing and adding namespace support. It will start trickling in soon.
alinspired 13y ago
google is probably holding the piece that competes with docker or openvz, they should have somthing like docker internally
- shykes 13y ago
  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.
  - thockin 13y ago
    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.
    - azinman2 13y ago
      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.

by shykes 13y ago

shykes 13y ago

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.

jamesaguilar 13y ago
> 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.proto https://github.com/google/lmctfy/blob/master/include/lmctfy.... Which attributes are you having trouble setting a useful value for?
- shykes 13y ago
  Thank you! I was scanning .h files for a type declaration.. Silly old-school me :)
  - jamesaguilar 13y ago
    I only knew because I've worked with the internal analogue of this library recently. Glad I could help.
- nickstinemates 13y ago
  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.
menage 13y ago
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).
- shykes 13y ago
  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.
  - thockin 13y ago
    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.
  - justincormack 13y ago
    The namespacing part is much simpler, if you have specific use cases.
  - SEJeff 13y ago
    Perhaps they'd be open to a collaboration where you add that functionality and then you use it to make docker (even more!) awesome.
- jnagal 13y ago
  We (lmctfy team) are in the middle of designing and adding namespace support. It will start trickling in soon.

alinspired 13y ago

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

shykes 13y ago
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.
- thockin 13y ago
  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.
  - azinman2 13y ago
    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.