Kubernetes-ready installation of the server

[cbosdo]

Installing Uyuni server on Kubernetes may not need an operator in the end.
The idea of this card / EPIC is to delegate the update / setup to initContainers. Basically the server container would run the setup as an initialization container, the DB upgrade and finalization as other init containers.
There are some assumptions for this to work:

1. those containers should be just checks if nothing needs to be done.
2. if the setup variables are changed, the container needs to be adapted (calling spacewalk-hostname-rename or satpasswd if needed).
3. each container deals with its upgrade steps.
4. if a dependent upgrade or setup failed, the other container needs to fail too.

Achieving this means that we have full control of what happens during the setup and upgrade phases.
While this is currently the case for upgrade it is far from being the case for the setup.
A preliminary task is to simplify and de-clutter the setup scripts in order to write more meaningful setup.

With this Uyuni server would only need to be a helm chart and mgradm could be limited to operate on the cluster to help migrating from a legacy server.

May be some of the YAML files generated by the helm chart could be used with podman kube play and quadlets... but that is another EPIC.

[cbosdo]

@admd @rjmateus this idea may be of interest for you

[rjmateus]

It looks interesting and is something we definitely need to research about. But not for 5.1, we are already too loaded.
The good think is that podman deployment is hidden on mgradm, so we can change all the pipes in a Major version, without many vivibility to customers.

[benled]

Is there a way do a setup without using mgradm?
As someone working with Kubernetes I would like to create a more cloud-native deployment with at least separating the Uyuni-Server from the Postgres and have more options to fine-tune the deployments.
No matter if using podman or Kubernetes that should be the way to go.
But unfortunately, I can’t find any public documentation or hints about how to accomplish that and/or how to push a specific config into the container/pod.

Also, when looking into Kubernetes, deployments should preferably be available by YAML files or Helm Charts instead of using a mandatory CMD tool to do everything in the background.
How can we get more insight into what mgradm attempts to do (without reading all the source code) to see why it is not deploying on e.g. RKE2?
As far as I see there are multiple tmp scripts, etc. created and executed, but they are deleted immediately.

[cbosdo]

Is there a way do a setup without using mgradm? As someone working with Kubernetes I would like to create a more cloud-native deployment with at least separating the Uyuni-Server from the Postgres and have more options to fine-tune the deployments. No matter if using podman or Kubernetes that should be the way to go. But unfortunately, I can’t find any public documentation or hints about how to accomplish that and/or how to push a specific config into the container/pod.

The installation for Kubernetes has been started using mgradm more than a year ago and I realized in the mean time that it doesn't make sense. I want to continue refactoring to install and upgrade with only a helm chart, but I'm not there yet. This card is a reminder for me 😉

Installation based on podman will still be done using mgradm as this is what is recommended for users who are not cloud-native yet to make things simpler.

Also, when looking into Kubernetes, deployments should preferably be available by YAML files or Helm Charts instead of using a mandatory CMD tool to do everything in the background.

100% agreed and this is the reason of this card.

How can we get more insight into what mgradm attempts to do (without reading all the source code) to see why it is not deploying on e.g. RKE2? As far as I see there are multiple tmp scripts, etc. created and executed, but they are deleted immediately.

Apart reading code there isn't much help. Using the latest code from main branch you should have a job for the setup that stays around for you to check the logs.