FESCo approved F41 change requests for versioned Kubernetes rpms (https://pagure.io/fesco/issue/3194) and CRI-O and CRI-Tools (https://pagure.io/fesco/issue/3218).
The plan for both approved changes is to deploy versioned rpms for Kubernetes, CRI-O, and CRI-Tools. I failed to note in the original change requests that these versioned rpms are not intended nor designed for parallel installs. The user will need to uninstall an existing version of, for example, CRI-O, and install the new version with dnf. I regret not being explicitly clear on this aspect of these proposals.
I seek, if needed, an explicit exemption from the packaging committee to deploy versioned Kubernetes, CRI-O, and CRI-Ttools rpms that are not parallel installable. The kubernetes1.30 rpm will conflict with any other kubernetes versioned rpm (e.g. kubernetes1.29). Both rpms will install the same files in the same locations on the host system.
CRI-O and CRI-Tools are designed by the upstream communities to match Kubernetes on the minor version. If, for example, kubernetes1.31 is installed, then cri-o1.31 and cri-tools1.31 also need to be installed. Patch versions can vary between components.
The Kubernetes update process does not support skipping versions (minor). To update all machines in a Kubernetes 1.29 cluster to Kubernetes v1.30, each machine, in turn, is detached from the cluster, the software updated, and then reattached to the cluster. Once all machines are running the new version of kubernetes, then the cluster as a whole is updated to match. This typically involves updating administrative pods running in the cluster. Offering parallel installs does not provide any clear benefit to users (with one exception - see below). Updating from v1.29 to v1.31 directly is not supported by upstream.
The one potential exception for parallel installs is the kubernetes command line client, kubectl. There are possible end-user scenarios where a kubernetes cluster administrator using a Fedora workstation and managing many clusters may benefit from having multiple versions of the command line client. However the benefit is not clear and will be explored in future releases of these rpms. For now, the client will be deployed in a non-parallel manner.
thank you for your consideration
I seek, if needed, an explicit exemption from the packaging committee to deploy versioned Kubernetes, CRI-O, and CRI-Ttools rpms that are not parallel installable.
I think this is fine. Not sure if we need to make a formal decision here since I'm not sure you need an exception. This use case is just "different packages provide the same files and they conflict" and it's not that special.
FESCo approved F41 change requests for versioned Kubernetes rpms
I think we can stop here. It got approved so these kind of obvious things to make it work are fine.
Metadata Update from @james: - Issue close_status updated to: accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.