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
But why the link of LXD under `Product’ section of above right corner still point to linuxcontainers?
Q. How can I access the release announcements and their translations?
For example, the content at the following URL:
- https://github.com/lxc/linuxcontainers.org/tree/1f13bcfbb26995010949c1d72e9718d0f97194c2/content/lxd/news
- https://github.com/lxc/linuxcontainers.org/tree/1f13bcfbb26995010949c1d72e9718d0f97194c2/content/lxd/news.ja
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.
We are still in the process of updating all links and references. It will be changed shortly.
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
“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
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
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
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.
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
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
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.
I absolutely second that.
Dropping community support (or severely limiting bandwidth) is going to strangle LXD.
I understand need to lower burden on core developers, but that’s exactly what community-powered forums are for.
Note: I wouldn’t have posted this (contributing to sheer noise) if not for the need to “upgrade” my user status.
Hi @ablomberg
There are no plans to restore building images for those architectures and distributions.
The images supported by Canonical are those available on the ubuntu: remote.
See:
lxc image list ubuntu:
The community images are maintained by the https://linuxcontainers.org/ project for use with LXD and LXC.
That’s what I was afraid of. I guess the days of a free lunch are over. It was good while it lasted.
Thank you for the confirmation.
3 Likes
Hm, that’s sad. I’m troubleshooting a bug in ubuntu armhf that does NOT happen in debian armhf, and I was hoping to be able to spin up a debian armhf container, but I see the armhf images are gone from the default images: remote.
Since I was working on this bug on a Sunday in my free time, I guess I’ll stop here.
1 Like
I’m disappointed to learn that the images: remote will no longer be available for LXD, as announced here.
It appears that I now have to decide between continuing to use LXD or transitioning to Incus.
Is there any plan for LXD to introduce a fork of images: or alternative methods to address this change?
Additionally, I’m concerned about the future compatibility of ubuntu: images with Incus. Will Incus still be able to use these images, or are there potential issues on the horizon?
Thank you.
1 Like
Yeah this is a major blow. We rely on images: specifically alpine images containers. Without images: support we will be forced to move to incus.
@tomp does canonical have plans on continuing support for images: ?
You can use Incus to export an image from images: and then import it to LXD. I use both Incus and LXD, and I typically build and export images on one platform that I then use on both Incus and LXD systems.
It’s a good idea to use images that you’ve imported to your system, rather than getting the latest image from “images:” whenever you need it, because the latest image may have bugs or changes that break your instances. This has happened to me several times in the past, so I no longer build containers directly from “images:”, except once in a while to build a container that I then publish as an image.
It’s also a good idea to learn to use distrobuilder so you can build your own images from scratch, just in case. For example, there is no images:alpine/3.19 image yet, but you can make your own using distrobuilder.
As for compatibility, I hope LXD and Incus can agree on a standard image format that they both use. Apparently the format is the same for now, but there is no guarantee that it will remain so.
1 Like