Discussion: New host Operating System for Uyuni #9729
Replies: 11 comments 19 replies
-
|
I want to do the least work possible in maintaining Uyuni, both in the short and long term. So whatever path that is would be my preference. We found migrating to containers less than a year ago was a very involved process (partly because we tried to run it on a different OS and that wasted two days before resetting and starting over with the recommended MicroOS). Gotta say that I'm not overjoyed at the thought that there may be another major migration process so soon after that, and I hope the process is well documented as we're not familiar with MicroOs nor Tumbleweed. |
Beta Was this translation helpful? Give feedback.
-
|
Sure. The idea here is that this is going to be THE final migration. As for not being familiar with them, the good thing is they are basically the same as using Leap/Leap micro, but they are rolling release so there are no major or minor versions that can require changes on the repositories or anything similar like we used to have. |
Beta Was this translation helpful? Give feedback.
-
|
As talking about containers, let's consider Alpine which is the most widespread base image :) |
Beta Was this translation helpful? Give feedback.
-
|
As for the package dependencies or services broken, at least on openSUSE MicroOS the only thing I noticed in several years was one broken kernel, that could be fixed by going to the previous snapshot (in fact I have automated updates, so it rolled back automatically and I only noticed because I have monitoring for that openSUSE MicroOS And as mentioned the stability also goes in the sense that Uyuni does not have many dependencies as it's now working as containers, so the chances of broken dependencies are small, and services are not required, other than things like (of course) SSH. |
Beta Was this translation helpful? Give feedback.
-
|
Would this change still happen if Leap Micro was released once per year? |
Beta Was this translation helpful? Give feedback.
-
I can't follow this argument. MicroOS is an upgrade every snapshot. Leap Micro is an upgrade once a year. Why do we avoid migrations when we increase the number of upgrades?
There is ongoing work for a migration tool . Anyhow, I don't think there is a big difference between sticking to Leap Micro and going with MicroOS. It's the old "spread upgrades over months" vs "upgrade once a year" debate with no universal answer. |
Beta Was this translation helpful? Give feedback.
-
Yes, but you don't need to reinstall because of a OS new version. It's rolling release.
True, but there's to be seen when it will be come officially included. And nobody is to tell that at some point a OS new version will just not work. Besides, you need to run the migraton tool... which is not required for a rolling release.
It's rather about "all of your upgrades/updates are basically the same" (rolling release). Be it for MicroOS or Tumbleweed. |
Beta Was this translation helpful? Give feedback.
-
You don't need to reinstall Leap upgrades either. The Leap upgrades are, in a sense, aggregated Tumbleweed upgrades. Anyway, I still think there is not a big difference. |
Beta Was this translation helpful? Give feedback.
-
|
If Uyuni can't keep up with Leap Micro releasing twice per year I can't see how a continual rolling release will help things. I also don't see how this will help with SUSE Manager on SL Micro but I guess that's not Uyuni's problem. |
Beta Was this translation helpful? Give feedback.
-
|
On the development side, the continual rolling release helps avoiding a lot of changes that otherwise are needed (most of them, but not all, are listed on the first message). For SUSE Manager, that is a different story, but having Tumbleweed/MicroOS means whatever they will have, will end up landing on SUSE Linux Enterprise (and Micro) with new service packs and/or new versions (as per the Factory first policy). |
Beta Was this translation helpful? Give feedback.
-
|
Given that container-based Uyuni doesn't upgrade itself (i.e. manual decision/action by admin) I'd be a bit concerned by the host OS auto-updating. If it should (still) work on Leap Micro 6.x then that's what I'd use. Which OS will be used for Uyuni container? |
Beta Was this translation helpful? Give feedback.
-
|
The host OS auto-updating can be disabled if the administrator desires to have it this way. This is something we'd need to document even if for openSUSE Leap Micro and the fact we don't have it already is a bug in the documentation. For reference, this is what SUSE Multi-Linux Manager 5.0 documents, and it's 100% valid for the existing Uyuni 2024.12:
For the OS to be used for the container itself:
|
Beta Was this translation helpful? Give feedback.
-
|
BTW, about this:
Same as others are using Debian or already openSUSE MicroOS. Just be aware that we don't have resources ATM to validate it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the replies. To me it feels like a decision has already been made so we'll just have to work with (or around) it. |
Beta Was this translation helpful? Give feedback.
-
|
There will be a poll about transactional or not, but don't focus on the host OS auto-updating, as disabling them is still allowed on openSUSE MicroOS (it's not mentioned for now for the current Leap Micro as this is a bug at the Uyuni documentation). |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps Uyuni should not care so much about the container host OS - since we really care most about the base container image itself. We need only be opinionated on what we test. It may make some sense to offer Uyuni to run on the host OS of the community users choosing/responsibility with a few caveats.
|
Beta Was this translation helpful? Give feedback.
-
|
For now, there are limits to what we can handle, so first we need to pick the opinionated OS that to use for CI, which short term at least is going to be the OS for we can always say that will work with each new version :-) |
Beta Was this translation helpful? Give feedback.
-
|
Your summary of user impact may be tempered in a virtual environment by simply creating a new container host OS instance, mounting the previous persistent storage on '/var/lib/containers/storage/volumes' and running the appropriate mgradm command. This need only be a few minutes of disruption. Most Uyuni users are not installing with sumaform. |
Beta Was this translation helpful? Give feedback.
-
|
For anyone who's reading this and hasn't yet given an opinion; please do. I'd be interested in a broader viewpoint. Only six voices so far, which feels quite few. Developers are always so deeply involved in a project (any project, not just Uyuni) that sometimes the things that they find easy and may consider trivial are the points that cause dismay and trouble for users. Sometimes these are also the least documented for the same reason and assumption is made about the experience of these environments is assumed. Migration is a big deal to me and not something I'd like to do more than once every four or so years. But perhaps I'm the only one? |
Beta Was this translation helpful? Give feedback.
-
|
Just for clarification: It says above that "The containers images will remain to be built on top of openSUSE Leap, so this change is only about the host Operating System. No Java, Python or similar stack update from Tumbleweed/MicroOS would affect the containers.". Is this correct? When I mgrctl term into the container it looks a lot more like SLES 15 SP6? uyuni-server:/ # cat /etc/os-release | grep 15 |
Beta Was this translation helpful? Give feedback.
-
|
Our Uyuni server host has been using openSUSE MicroOS. I have disabled auto updating, and it's currently at 20250127. I've not had any issues using openSUSE MicroOS up to Uyuni 2024.10, and have done at least 1 Uyuni / MicroOS update since building it without any issues. Install and setup of openSUSE MicroOS was a lot easier than openSUSE Leap Micro so that is a positive from my perspective. I do have some concerns about using a rolling release and Uyuni having an issue with something in the OS update and it taking a long time for a fix to get released for Uyuni. Typically Information Security is more concerned about us having all OS related security fixes in place, and specific application security fixes are a secondary concern. Being able to keep openSUSE MicroOS current and having Uyuni tested and supported on the latest release of MicroOS, with an emphasis of making sure that fixes for Uyuni are prioritized to make sure it's working on the latest host OS release seems like maybe the best balance of living on the bleeding edge, and also making sure we take OS security fixes as quickly as possible. As for using Tumbleweed, I don't see much benefit moving to Tumbleweed. As was called out openSUSE MicroOS is just a cleaned up and minimized version of Tumbleweed designed to run containers and with transactional OS setup. Having the transactional OS and a specific containerized host OS seems to make the most sense, why add the ability to run it in a non transactional OS? Just my 2 cents and thoughts. |
Beta Was this translation helpful? Give feedback.
-
|
It's correct. You see SUSE Linux Enterprise Server 15 SP6, as we use the BCI (Base Container Image), but then on top we install all the packages from openSUSE Leap 15.6. In the end base OS share most of the packaging since the Closing The Leap Gap project was finished. No matter whatever it's decided in the end, openSUSE MicroOS should keep working just fine with the containers, so do not worry. But it's great to see it's working already on top of openSUSE MicroOS and succesfully, as it helps with already real-world feedback! |
Beta Was this translation helpful? Give feedback.
-
|
We successfully migrated from Uyuni 2024.08 to 2024.12 using Ubuntu 24.04 as our "Podman host". Will there be ongoing support for containerized Uyuni on Ubuntu with Podman? If not, would there be a migration path off of Ubuntu Podman? |
Beta Was this translation helpful? Give feedback.
-
|
You will be able to keep running on top of Ubuntu as of now, with Podman. It was never tested on our side, but it should work, and we appreciate as much feedback as people may provide about the experience. At the very least we need to pick an OS that we can certify for each release (this could change in the future), so that's why we are asking if openSUSE Tumbleweed or openSUSE Tumbleweed. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight here. Uyuni 2024.12 in Podman is very solid and performant hosted on Ubuntu 24.04. We have roughly 500 minions under management and that number will continue to increase going forward. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, community, as we'll need to get ready for a new Uyuni release, we need to get ready for the decision. So far it seems we have some people already using it on top of openSUSE MicroOS, so as that's validated already, seems to be a reasonable choice. Needless to say, other OS that were already working, should still working, such as Ubuntu, Debian, openSUSE Leap 15.6 or openSUSE Leap Micro 6.X. Remember this is to decide what we validate before we release, which is what we (for now) document on the documentation and the release notes. Let's have some final time for any last minute discussions until Tuesday 18th 23:59 UTC. |
Beta Was this translation helpful? Give feedback.
-
|
The poll is now available at #9804 |
Beta Was this translation helpful? Give feedback.
-
UPDATE: Poll is now available at #9804
Hello,
As mentioned at the last Uyuni Community Hours, we are going to discuss a new host Operating System for Uyuni.
Current situation
As you know, in the past Uyuni was using openSUSE Leap as host, and a few months ago, with the move to containers, we decided to move to openSUSE Leap Micro 5.5, to use an OS specifically designed to run containers.
While that worked well so far, the problem is that the lifecycle of openSUSE Leap Micro is way too fast for being the host OS of Uyuni. Unlike regular openSUSE Leap, openSUSE Leap Micro gets a release twice per year, and as a consequence the lifecycle for each version is 12 months instead of the 15 months for the regular openSUSE Leap.
In addition, the openSUSE website is keeping visible only the download information of the most recent openSUSE Leap Micro version, so the documentation, site and others need to specifically include clear instructions on how to download the needed openSUSE Leap Micro version.
What bumping the host OS version means
For the users, this means:
For the development of Uyuni, this means adapting:
And of course anyone developing for Uyuni then needs to adjust things on their side for (at least) sumaform.
As you can see, those are no trivial procedures for either users or developers.
Proposal
We want to change the host Operating System for Uyuni Server and Proxy, to either openSUSE MicroOS or openSUSE Tumbleweed.
openSUSE Tumbleweed is a rolling release by openSUSE, meaning you install it once and enjoy it forever. No need to worry every six or twelve months about massive system upgrades that risk bricking your system.
openSUSE MicroOS is a rolling release and transactional product, designed to specifically run containers, and based on Tumbleweed (it uses the Tumbleweed repositories): https://microos.opensuse.org/
As you can see the biggest difference between openSUSE MicroOS and openSUSE Tumbleweed is that MicroOS is transactional and specifically designed to run workloads as containers, while openSUSE Tumbleweed is generalistic and is generally used as non-transactional (but for a while now can be configured as transactional).
There’s as of today, still one more difference: openSUSE MicroOS is not available at most public cloud providers, while openSUSE Tumbleweed is.
So this is the decision we need to make: openSUSE MicroOS or openSUSE Tumbleweed?
FAQ
A: We’ll do our best to allow installing on both OS, but for the moment we can only verify that things work on a single operating system.
A: As mentioned, the list of packages required by Uyuni is really, really small, as it runs as containers. Even if the worst comes to happen and a podman update becomes incompatible, rolling back to the previous snapshot would be possible, and then the rest of updates can be applied excluding podman, until we can release a fix.
A: Strictly speaking, it should be working already, but as already said we can only verify that things work on a single operating system. Needless to say, we are looking forward to the community to help, as sumaform, the pipelines, and most of what’s required is there, and we could provide some infrastructure to run validations in some cases, provided the community can help with the required changes to sumaform, pipelines etc.
Beta Was this translation helpful? Give feedback.
All reactions