So in general, we (as in Canonical LXD team) will be focusing on:
- Developing LXD
- Maintaining liblxc (the C library that LXC provides)
- Maintaining go-lxc (the Go binding for liblxc)
- Maintaining our image generation tooling (distrobuilder & jenkins)
We will happily do code reviews, give pointers, suggestions and help with design for the remaining components but as those aren’t critical to what we’re delivering, we won’t spend much time working on those ourselves:
- lxc-utils (the traditional C tools)
- lxc-templates (old shell image generation scripts)
- python3-lxc (python3 binding for liblxc)
- python2-lxc (python2 bindings for liblxc)
- lua-lxc (lua bindings for liblxc)
- ruby-lxc (ruby bindings for liblxc)
LXC using the C tools still has its uses, it’s daemon-less, allows for completely unprivileged containers (those started from an unprivileged user) and is also well suited for embedded environments due to its lack of daemon and very small footprint.
We expect most traditional users of LXC to migrate to LXD as it offers a better experience in general and allows for more poewrful use of containers, but those who have special needs for the traditional LXC experience (HPC users, embedded users, …), those can and I expect will stick to the C tools.
We have no plans to deprecate liblxc, in fact, we’re planning on moving some of the LXD features into it, to make them faster and available to users from C. We also will keep building a wide variety of images and keep adding new exciting features to LXD. That’s the focus of the containers team at Canonical, but other contributors have other priorities so I still expect a lot to happen in those other parts of the project.