FAQ: LXD has been moved to Canonical

LXD News
#1

This week, we made some changes to the LXD project and want to clarify what they mean for users. The changes pertain to the maintenance and hosting of the project: Canonical is now the main maintainer and the infrastructure is hosted by Canonical.

We are very proud that LXD has grown in both contributions and impact since its launch, with hundreds of contributors. This is a testament to the power of the community and we want to honour their contributions, which is why we will increase our investment in the project and continue to expand the team.

Over the years, Canonical has invested considerably in LXD, both in working with the community, as well as adding features for enterprise users and providing support. This commitment to the LXD project will remain the same going forward. Contributor guidelines and licensing will also remain the same.

This post answers the most common questions raised following the announcement.

What is changing?

LinuxContainers.org is an umbrella initiative covering several projects aimed at the development of Linux container technologies. Until now, these included: LXC, LXCFS, LXD, distrobuilder, libresource and lxcri.

While hosted under the LinuxContainers umbrella, Canonical was the creator and primary developer of LXD since its creation, and it has now decided to move the project to its own infrastructure.

This includes the following changes:

LXC, as well as other initiatives listed above, remain part of the Linux Containers project and will continue to receive contributions from Canonical. LinuxContainers.org, as well as its community forum, will remain available for all information and discussions regarding projects remaining under the LinuxContainers umbrella.

Why has Canonical made this decision?

The LXD project is continuously evolving, and in order to align with other Canonical-sponsored projects, we believe that LXD would be better served by being hosted on Canonical’s infrastructure going forward.

Canonical can provide a highly scalable infrastructure for the LXD project to live and grow on, and ensure robustness for the future. We also believe that moving the LXD conversations to the Ubuntu Discourse allows for greater community visibility, discussion, collaboration and potential contributions from a wider community. The Canonical docs team is also working to improve and standardise our product documentation. The move to our infrastructure will enable more robust documentation and a better experience for LXD users.

Does this move affect the LXD licence or contribution guidelines?

No, LXD will remain free and open source software published under the Apache 2 license. The contribution guidelines as well remain unchanged. We continue to welcome and encourage community involvement.

Does this move mean that LXD is now becoming Ubuntu-specific and purely reliant on snaps?

No, LXD continues to be distro-independent, and developed and distributed in the same way as it was until now. While we consider snaps being the easiest way to install LXD, other installation options are, and will remain, available, as outlined in our documentation.

How does this affect the future of LXD and the current roadmap?

Canonical remains committed to developing and improving LXD going forward. We continue to have a team dedicated to maintaining and developing LXD, and we plan to further grow the team in the future.

The commitment to the current roadmap, as outlined in this video, remains unchanged.

Going forward we will continue to share our future roadmaps publicly, and as before, we welcome input from the community in their preparation.

What does this mean for the LXD release schedule?

LXD has two types of releases: monthly feature releases, and LTS releases every two years that follow the Ubuntu release cadence. This schedule will remain unchanged going forward.

Due to the infrastructure changes, we do expect this might potentially cause delays with the next monthly release. But going forward, we will stick to the same release cadence as before. The releases will be signed by Thomas Parrott, using this key.

I’ve joined the Ubuntu Discourse, but I am unable to post a new topic

In order to prevent spam, the Ubuntu Discourse has a limitation for new users - they can’t create topics until they’ve entered at least 5 topics, read 30 posts (replies) and spent 10 minutes reading posts. New users just need to browse a little, open a few posts or post a couple of replies, and their trust level will automatically be raised.

Regarding using the Ubuntu Discourse

As part of the transition, communications around the LXD project from the LinuxContainers forums are being brought into the Ubuntu Discourse. This may include support-related questions which are typically directed to other community support platforms.

We are working on the best way to organize this in the long-term. Until this is completed, LXD support questions can be asked in the LXD - Support sub-category. This category is set up in a way that it does not interfere too much with regular usage of the Ubuntu Discourse.

We are considering all your feedback regarding this and will be doing our best to smooth out the process going forward.

14 Likes
Supporting the LXD Community
Weekly status #306
Ubuntu Weekly Newsletter Issue 795
#2

How do I create a new post? I can’t find the button on this forum. Has it been disabled?

Everything worked fine on the Linux Containers forum.

#3

That’s because this forum has been configured in a weird way to try and reduce spam…
You need to read a number of other posts prior to being able to make new topics of your own.

@ru-fu @egelinas

9 Likes
#4

Thanks for letting me know.

Question: How would I know that I need to “read” a certain number of posts, unless I asked?

How can I become a trusted user, because I am already trusted on the LXC forums?

#5

We are looking into whether that restriction can be relaxed or lifted.

2 Likes
#6

Thanks guys. I just got upped a “trust” level by posting a couple replies, so now I see the New Topic button.

8 Likes
#7

I’ve added a question about restrictions for new users in the FAQ above.

1 Like
#8

You should have received a greeting message from a bot account after you signed up - it has a link to the information about trust levels and when you get them.

1 Like
#9

But why the link of LXD under `Product’ section of above right corner still point to linuxcontainers?

#10

Q. How can I access the release announcements and their translations?

For example, the content at the following URL:

Q. Are individual URLs under linuxcontainers.org/lxd/docds/latest returning a 301 status code?

If they do not, could it result in dead links for all the documents across the web that have previously linked to those resources?

I trust you will give the community proper context and recognition for its contributions to date.

#11

We are still in the process of updating all links and references. It will be changed shortly.

#12

All previous (and future) release announcements are available here on Github. The corresponding forum and news posts on linuxcontainers.org remain accessible. Going forward, we won’t have a ‘news’ section as before, but all release announcements will be posted here (and linked on Github) and translations to other languages are more than welcome.

Regarding your second question, the new URLs do return a 301, but they now redirect to the statement, not to the corresponding URLs in the new docs. We understand that this might cause some inconvenience to the users.

4 Likes
#13

“Actually” the rate-limiting stuff wasn’t really to do with spam on this site. It was more to suppress support requests. This site was not originally intended to be used for support for Ubuntu products. We have other sites like AskUbuntu and the Ubuntu Forums for that, and they do a much better job - being well-established communities, with many eyeballs and high Google search rank.

When we turn off/down the limits, we’d get people signing up here and asking all manner of support questions (printers, GPU drivers, everything). Even though we had banners that indicated boldly that this is not a support site, people ignore that and would use it for that anyway.

We spent a fair amount of time closing threads, and re-inforcing that rule. The limits suppressed this quite dramatically down to almost zero.

I appreciate that the LXD community discourse was used for support, and thus migrating that community here will have some friction due to these conflicting requirements of discourse. I would recommend that the powers that be (not me, as I left Canonical a couple of years ago) think this through carefully. Otherwise, you’ll get not only well-intentioned LXD support tickets here, but also Ubuntu and all other Canonical product support requests here. Without the eyeballs/community to answer them.

Just my 2p

7 Likes
About the Support category
#14

IMHO LXD discourse was a life saver for lxd users. If this rate limit or so on is imposed not sure it would make sense for average user to wait for approval/delay. I sometimes think it would be nicer to move to github discussions as it is one place for both referring/seeing related issues.

4 Likes
#15

Whether the move for LXD questions and answers from discuss.linuxcontainers.org to discourse.ubuntu.com was really such a good idea? I doubt that the search for lxd related problems and solutions between all these ubuntu questions will work as expected in such a way. Maybe it would have been better to start an AskLXD at Stack Exchange or a separate discourse platform - but why???
There probably marketing had their fingers involved in that decision to move and have not thought until noon … all very difficult to understand and not convinced …

1 Like
#16

All previous (and future) release announcements are available here on Github.

Thank you for the information. I would greatly appreciate it if you could revive the translations of past release notes, even on GitHub.

but all release announcements will be posted here (and linked on Github) and translations to other languages are more than welcome.

Do you have any tips for translating and publishing useful posts like the release announcements on discourse.ubuntu.com? Should we simply comment on the translated version? Is there a way for multiple users to review and correct, like in git PR/MR?

We understand that this might cause some inconvenience to the users.

I understand that it’s inevitable to have deadlinks at this point. I’m looking forward to them being fixed in the future.

#17

Thank you for your feedback. This is important for us, and we are discussing how to set up things in a better way in the long term.

Clarifying the issue you experienced earlier - this is the place to ask support questions. Not everyone was aware of the changes we are considering and we are working with the Community here to find the best approach for this. We have set up a new LXD - Support sub-category. This category is set up in a way that it does not interfere too much with regular usage of the Ubuntu Discourse. The LXD team will be answering questions there, as usual.

I have updated the FAQ with a section on this as well.

2 Likes
#18

I found my way here because the images published on images.linuxcontainers.org suddenly removed all the 32bit images for debian on armhf. My apologies if this is the wrong place to ask this question, but will the removed architectures from images.linuxcontainers.org be restored using canonical resources, or am I out of luck and now need to start building my own images by hand for armhf? I was relying on this infrastructure for building deb packages for raspberry pi 3b+'s using debian 32bit images. Fortunately I still have the last published images stored on several cloud VMs and was able to export them, so my CI pipelines are not completely broken, but I would like to know what the plan is for these lost architectures moving forward.

Thank you for your time and attention.

-A

1 Like
#19

The LXD Go code import path has changed to github.com/canonical/lxd.
Wouldn’t it be better to have set it to canonical.com/lxd? The code can still be on github, but setting the import path to the canonical domain would be closer to using canonical’s infrastructure and branding, instead of using github’s branding. All it takes for this is a simple http server on canonical’s domain that points go imports to the github repository. It’s like having email on one’s own domain, while using another company’s email servers.

#20