No, Docker is not build on lxd. It used to be built on lxC, which is now an optional backend.
The grand-parent is correct that lxd is a newly introduced competitor to Docker.
I won't comment on whether it's good or bad, but it's an objective fact that canonical decided to reimplement what Docker does rather than contribute to it.
Don't worry Solomon, we still love Docker and will continue to use it :)
That being said, if they do somehow manage to get hardware assisted containment for containers, I see it as a no-brainer for docker to adopt it as soon as it is reasonably possible. Are there any plans (that you can speak of) regarding something like this, or are you waiting for LXD to be more than vaporware at this point?
I can say that there are employees of major silicon companies already working on contributing all of this to upstream Docker. I was shown a real proof of concept already, it's very promising and not at all vaporware :)
> it's an objective fact that canonical decided to reimplement
> what Docker does rather than contribute to it.
What was the reason that Docker reimplemented much of LXC rather than contribute patches upstream?
Latest LXC supports features that Docker's reimplementation doesn't, and it seems likely to get further ahead feature-wise now that Ubuntu is pouring more resources into LXC/LXD.
You forgot to quote the part where I said "I won't comment on whether it's good or bad".
Canonical doesn't need to justify itself to me, no more than the Docker maintainers need to justify themselves to you. It's just how open-source works: you weigh the pros and cons of re-using vs re-implementing, make a decision, and see if the community follows you. In the case of Docker, the community followed. In the case of lxd, I guess we'll see. Either way, more choice and competition means the user wins.
Happened to find the pull request discussing the lxc-driver issue. It sounds like there was some interest in contributing upstream, but it didn't really go anywhere.
https://github.com/docker/docker/pull/5797
From the thread, it seems like the concern was just that lxc-exec wasn't well maintained and the lxc interfaces weren't stable since it was undergoing heavy development. I think that's changed recently with both lxc and docker now post 1.0 release and 'production-ready'.
Docker still uses LXC if you want it to via the lxc-exec driver and the --lxc-conf option. It's just not the default, which probably makes sense since the lxc options mainly apply for advanced users.
So by default, Docker uses libcontainer for a simpler installation experience. But for advanced users, using the lxc driver is an option to look into.
IMO, Docker wins if it continues to play nicely with the other open-source projects people use with Docker, and also give credit where due.
The grand-parent is correct that lxd is a newly introduced competitor to Docker.
I won't comment on whether it's good or bad, but it's an objective fact that canonical decided to reimplement what Docker does rather than contribute to it.