Any update on LXC template support beyond Debian 12?

[amlucent]

I was reading this discussion
where it mentioned:

🌟 Future Preparations: Enhanced readiness for Fedora, CentOS, RockLinux, AlmaLinux, and openSUSE as LXC installations.

Is that still in progress?

The reason I ask is because I’ve got a few older LXC containers that were originally deployed with tteck’s scripts on Ubuntu, but it looks like Ubuntu templates aren’t supported anymore. I also have some Debian 11 containers that I need to move off since 11 is now EOL.

Ideally, I’d like to migrate those to something with a longer support cycle—like Ubuntu LTS or Rocky. Just wondering if that’s on the roadmap, or if Debian 12 will be the only community-supported option going forward.

[MickLesk]

Ubuntu is available, or are this Templates an very old 20.04?

Yes in next weeks there will be added the current available Templates (with pveam available)

Edit: but these Versions are Not for General work of all Scripts. They will be available as LXC (Like Default alpine, Debian, Ubuntu LXC)

[amlucent]

I see.

Not for General work of all Scripts.

Yes I am asking about the base template for the app scripts. ttecks old app scripts would offer choice between multiple Debian and ubuntu versions. To confirm, this project currently has no plans to offer something like that in the future?

[MickLesk]

No, we removed this for normal Users. Caused to many Issues.

And you need to understand, If you use opensuse, thats not apt (zypper), or at Fedora its dnf. All Scripts working with apt(-get)

[amlucent]

And you need to understand, If you use opensuse, thats not apt (zypper), or at Fedora its dnf. All Scripts working with apt(-get)

I understand this previously supported feature added complexity. I believe in theory, multi-distro package installs could be managed with a bit of if/elif/else logic to account for different package managers and package names.

That said, my point isn’t about “please support my favorite distro” but more about lifecycle. Right now we’re looking at ~3 years of support with Debian, whereas something like Ubuntu 24 LTS or a RHEL variant (e.g. Rocky) would extend that closer to 10 years. Or you could even offer a stable rolling release distro.

From a user perspective, the challenge is having to either migrate or do in-place upgrades on older Debian-based LXCs. One possible way to ease that pain could be automated OS upgrades within containers, or even an automated migration into a fresh container on the latest supported release.

I am very much grateful for the project as it is today and I just want to share this as feedback and understand if I am performing lifecycle maintenance in a way counter to best practice..

As a maintainer, how do you envision and recommend folks managing longer-lived workloads handle lifecycle upgrades like this?

[michelroegl-brunner]

I can here what you say but this is no easy task. We focus one one Distro (Debian) for a reason. We are not even remotly close in terms of manpower to add support for more than one distro. The amount of testing and scripting needed for that is simply not feasable, as we already saw in the past where we had only debian/ubuntu. There is simply to much wich can break.
Also i like your idea of automatik migrations. But how do you expect we maintain this for over 350 Apps? If you can come up with a automatic/general system feel free to open a PR.

But tldr; What you are asking here is something the four guys working in there spare time on this projekt can not provide what you ask for. For the time we stick to Debian.