I would like to propose a Consensus process for new features and hope it doesn’t sound disrupting.
This would help LXD team to get a more reliable input from users about desired features, directions by majority vote of community, only as suggestion or food for thought.
This would replace the status quo of single individuals’ pull requests at github or discussions…
Final decision of course lies upon LXD Team, considering aspects like feasibility & overall integration with existing code.
Based on same mechanism, LXD Team could post future projects and measure the popularity as sort of decision-making tool.
Is there a particular issue that this is trying to solve?
In general, I’ve had absolutely horrendous experiences with any system that purposes to have suggested features and people voting on them. Most of those just end up getting ignored down the line, making people feel ignored.
With LXD, we try to focus on people’s problems, what do they want to solve and then keep that in mind as we work to grow different areas, that’s in contrast to such feature suggestion/voting systems which tend to focus a lot on the how rather than the what and the why.
On the community front, everyone is obviously welcome to work on whatever they want and send draft PRs, though we’d usually recommend opening an issue first just to avoid wasting time if it’s not something that we feel makes sense for the project.
On the company front, a few of us, especially @mionaalex@tomp and myself keep an eye on common pain points, various requests and issues, triaging what’s up there (and asking for issues to be filed when needed) as well as keeping an eye for any larger piece of work that we should commit company resources too.
I feel that the LXD team is sometimes too eager to add features to LXD. The response to addressing issues is excellent. Yet there could be some improvement in explaining certain significant additions to LXD. I discuss a couple of major additions to LXD below.
In July 2022, the S3 API was introduced. I couldn’t understand how it fit into LXD. The “why” that was mentioned was “feature parity with most public clouds and so a feature that workloads may come to expect.” The forum topic jumped immediately into the technical specifications, the “what”. Even though I wanted to ask “what does this have to do with containers”, I refrained, because the technical specifications were too much technical detail from me. Perhaps it would be better to discuss the “why” first, and then move into the technical specifications.
I recently tried the S3 API. I’m glad I did, but now that I understand how it works, I still don’t see why it is part of LXD. It seems that it simply piggy backs into the LXD client/server framework. It has nothing to do with containers. It uses some of the storage facilities of LXD, but is that enough justification for adding it in? Couldn’t it just as easily be a separate product? A separate snap? It is mostly a wrapper for other products anyway.
The reason of “feature parity with most public clouds” could be explained better. Is the roadmap of LXD to offer features to build public clouds? Is there going to be an LXD DNS service, where I can define and serve DNS zones for my domains? How about an LXD email service that sends and receives mail on behalf of containers? Is there a plan for LXD to be able to manage docker/podman containers?
In 2019, LXD virtual machines were introduced. At first I was skeptical. I thought, why is the LXD team spending resources on VMs, instead of making containers better? Yet, I now think that it was the right decision. I tried using qemu and kvm without LXD and I gave up. LXD made managing virtual machines almost as easy as containers, and I now use them.
I don’t know about a “consensus process” but discussions and presentation of the roadmap with less technical focus would help knowing what to expect and would allow us to give more feedback on the direction of LXD.
Getting more of the why is definitely something we’re quite keen on and something that @ru-fu has been steadily working on.
For the two you mentioned, in the VM case, it had been something that our customers had been requesting pretty much since the beginning but which we didn’t really want to tackle as we felt like libvirt had a good chance to do a better job there and had quite the headstart.
After a few years of focusing only on containers, making containers feel more and more like VMs, we noticed that very little had moved on the libvirt side, still no solid REST API, still no easy image based flow, still no defaulting on modern VM hardware, … You could get most of that through something like OpenStack but that’s a massive beast.
The other issue was that a lot of our users were running both containers and VMs, typically using LXD for containers and libvirt for VMs. That required defining network and storage in two different tools, running into resource conflicts when both get busy and two completely different ways to manage them.
In the end, while we were initially quite skeptical, we’ve been very very happy with the result. Having the option to trivially mix and match containers and VMs has been very welcome.
On the S3 front, we’ve started seeing more and more applications that are designed to be “cloud native” and that effectively assume that they have access to an S3 compatible data store.
This includes anything from asset storage on an HA deployment of Discourse to backup handling in a variety of software. Having that in LXD makes it easy to keep deploying those workloads without having to rely on a 3rd party service running outside of your infrastructure.
