COcontingencies·Nov 7, 2014
I've spent a lot of time looking at this area in a cross-platform way (ie. distribution-neutral, even OS-neutral, even 'service code execution environment might be a language VM instead of an OS' type ways / smacks of erlang, clojure or embedded development). Ubuntu contributions may be interesting but there's a few things in this statement that stuck out to me:
(1) Serge Hallyn moved to Ubuntu a fair while back. He was one of the two original LXC developers. We were in touch about 2009/2010, before he moved. The kernel features were IIRC originally funded by IBM with a view towards more efficient allocation of resources on their mega-scale platforms, but apparently failed to get adequate traction against the rest of industry which is parallelizing on commodity hardware.
(2) CRIU's DOOM demo is a loaded one. Moving containers around is ve
Read the rest
ry cute, and has definite appeal to less technical management who perceive it as adding flexibility, however the real tradeoff here is random weirdness across your application or service's execution (from probably-OK latency spikes to probably-not network stream accounting interruptions on third-party devices and associated layer 2 and 3 security hiccups) for assumed portability. These days, that's a crutch, albeit a useful one - particularly for very specific cases such legacy applications you can't rewrite requiring very high uptime - but not something to use if you can avoid it. Removing the monolithic assumptions in your service and incorporating node-failure and a distributed execution model is generally a much better idea... cheaper hardware, lower blood pressure, lower TCO, higher uptime.
(3) Our primary design goal with LXD, is to extend containers into process based systems that behave like virtual machines. What does that actually mean? For one, workflow considerations are not at the fore. It also means hybrid paravirt/container or hybrid third-party-cloud/local infrastructures are still going to need another management layer to abstract the various portions of infrastructure in to a common interface (as will services relying in whole or in part on non-Linux OSs or execution environments). These are a big part of the infrastructure and process challenge in many/most modern environments. As far as the 'extending' part goes, mostly LXC already offers everything, though the plethora of paradigms available for security, storage, resource allocation and QoS represent a relatively imposing research and execution challenge to even the most hardened Linux users: there's some ease of use work to be done, but how to achieve the same without sacrificing flexibility?
(4) our customers are, in fact, asking us for complete operating systems that boot and function within a Linux Container's execution space, natively [...] Ubuntu boots unmodified in Linux Containers today. That's the very easiest thing to achieve and has in fact been considered the 'lazy way' of using containers rather than writing custom applications with carefully crafted chroots and minimalistic dynamically-linked library dependency trees, refining custom kernel security toolkit policies for your application to back up carefully considered capability restrictions for the container, network namespaces with additional restrictions, custom cgroup-based multi-subsystem resource caps, etc. The fact that some distros assume they in full control of the hardware during their init process is largely resolved these days ... and I'd wager with very little to no thanks to LXD, except perhaps internal lobbying within Ubuntu.
(5) "Cloud Solutions Product Manager" version: LXD is a whole new semantic ... meaningless. Coder version from https://github.com/lxc/lxd : "a REST API, command line tool and OpenStack plugin based on liblxc". 'Nuff said.