Where We're Going With LXD

Hasn't Canonical learned not to overpromise and underdeliver? Examples are multiple, Juju, the Ubuntu Phone, etc.

Oh, and speaking about Juju and what Canonical hasn't learned, it appears it still hasn't learned that when it announces something, it has to explain in clear terms what it does. In the same vein that "Juju is DevOps distilled", LXD is everything and nothing. It's a hypervisor, but it's not really a hypervisor. Now I did my own research, and after heroic effort I think I understand what this supposedly is. Mind you, I am not sure, but here goes nothing.

LXD is tooling over Linux namespaces, cgroups and associated technology that uses CRIU, or something like CRIU (is CRIU even production-ready?) that manages containers, and can move containers between different hosts.

Now this is one phrase that I think everyone understands. Instead of this we got vague statements evoking delusions of grandeur, unwarranted comparisons to virtual machine, inappropriately and misleadingly using the word hypervisor, and mentions of Ceph and OpenStack. And we still haven't learned what the supposed hardware-integration is. They say they can't say because of contractual obligation. That sounds lame, but whatever, if they can't tell us what it is, why mention it at all? To check a buzzword from the list of used buzzwords?

Now what is the purpose of this thing? I genuinely don't know. What's wrong with docker? Docker can't move containers. Surely that can be solved (IFF it can be solved) easier than creating all this contraption from scratch. Docker is supposed to run processes while they seem to want to run full Linux distributions. Is that it? I don't know. Why do they even want to run full Linux distribution? We don't know. It might have something to do with the fact that this is what Juju expects. It might not, who knows.

I'll stop speculating here because we have very little to work with.

This is the most interesting part. Anyone want to guess? I'm having a hard time - from a hardware perspective contained processes are currently no different from any other processes, taking advantage of the standard user/kernel divide that hardware has supported for decades; they're merely namespaced differently by the kernel. How do you inject hardware into that?

(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 very 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.

Can a please moderator change the link, or mark this as a dead submission?