Directions and roadmaps

I’ve been trying to ascertain future directions for both lxc and lxd.
To my fairly uneducated eye it seems that lxd is the future direction of the combination of these two projects. What is not clear is how lxc fits into this future.
Does lxc continue as a separate entity?
Does lxc become part of the background under and behind lxd?
(More like lxc is subsumed into lxd as like lxd is a meta-set which includes lxc.)

Not meaning to be frustrating but there is no mention on the webpages of linuxcontainers of any kind of roadmap. It would be useful to even just the users to understand the present directions that the development team has.

TIA

1 Like

LXD and LXC are separate but tightly coupled projects. In fact, LXD builds on top of LXC. Simply put: LXC is a C API for managing containers and LXD uses Go bindings into the LXC API and abstracts away all of the nitty-gritty low-level details. The goal of LXD is to make interacting with containers dead simple. The goal of LXC is to provide a full-featured, thread-safe, low-level C API for containers. @stgraber might also find a few choice words to explain this. :slight_smile:

I am hoping that the " . . . few choice words to explain this." aren’t tinged in blue (reference to an english colloquialism for non-english 1st language people) - - - grin!!

I think I better understand this combination now.

What I think I’m hearing is that LXC is continuing but that by using LXD I don’t need to worry about the low level nuts and bolts and focus more on the usage of and in the containers.

Is there any advantage to loading lxc onto the system as well?
Is there any ‘greater usefulness’ that occurs by understanding, and using, the two jointly rather than just using lxd as the face of this system?

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.

3 Likes