Latest revision as of 14:24, 14 October 2024

Multiple Versioned Kubernetes Packages

Summary

Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release.

Owner

Name: Brad Smith
Email: bradley.g.smith@gmail.com

Current status

Targeted release: Fedora Linux 41
Last updated: 2024-10-14
Announced
Discussion Thread
FESCo issue: #3194
Tracker bug: #2276440
Release notes tracker: #139

Detailed Description

The Kubernetes project maintains 3 concurrent versions with a new release every 4 months. Each version has a defined life-cycle of approximately 1 year (https://https://kubernetes.io/releases/ for details and current versions). In this proposal a release is a major:minor version combination such as 1.28 or 1.27 and ignores any patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same 1.28 minor release).

We currently match one version of Kubernetes with each Fedora release. See https://src.fedoraproject.org/rpms/kubernetes for the list of Kubernetes releases by Fedora release. Due to the differing release cadences between Fedora and Kubernetes this means that a new release of Fedora may not have the most current release of Kubernetes. And, given that the Kubernetes cluster upgrade process does not permit skipping major:minor releases, not providing a Kubernetes release in Fedora so that the most current Kubernetes release is available when a Fedora release goes into production becomes a barrier to using Fedora as a host OS for Kubernetes.

We propose to create packages for all current Kubernetes releases for each Fedora release starting with Fedora 40. The package name would follow the Fedora naming convention standard for multiple package versions of "kubernetes[major].[minor]". Using the kubernetes-client rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora would offer kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41, and kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes versions available will depend on what is supported upstream.

We also propose that there not be any default version of Kubernetes for a given Fedora release. Fedora would not provide a kubernetes-client-1.30.1-1.fc41 package available, assuming that Kubernetes 1.30 is the "default" for Fedora 41. Default versions coupled to a given Fedora release can result in unplanned version updates to the installed Kubernetes version (i.e. v1.28 to v1.29) which can adversely affect cluster functioning.

It is also important to note that each Kubernetes release is built with a specific version of the Go language. The version of Go available in a Fedora release will potentially be a constraint on which version of Kubernetes can be provided for an older Fedora release.

We also maintain a Kubernetes page on Fedora Quick Docs with information about the change and how to install Kubernetes using Fedora provided packages.

Feedback

To be provided.

Benefit to Fedora

Fedora becomes a first class platform for Kubernetes using packages from Fedora repositories. That is, all current, maintained releases of Kubernetes are available in the main Fedora repositories, subject to the Go language constraint. This allows Fedora, as a host OS for a Kubernetes cluster, to be maintained and upgraded independently of the Kubernetes release used by the cluster. This also allows the cluster to be upgraded independently of the Fedora release using Fedora provided packages.

This also means that a Kubernetes cluster administrator using Fedora as their workstation can install and use or retain the appropriate Kubernetes command line client, kubectl, that matches the release of the cluster. Updating to a new Fedora release will not inadvertently install a command line client that is not compatible with the release version of the cluster(s) managed by the user.

Scope

Proposal owners:

With each new minor release of Kubernetes, package owners would request a new repository on src.fedoraproject.org from engineering similar to what the nodejs team now does for the parallel-installable versions of nodejs. Documentation would be refreshed to inform users of the new version and what specific Fedora releases the new version of Kubernetes would be available on.

Other developers:

Releases of cri-o and cri-tools are version matched with Kubernetes release at the major:minor level. Cri-o uses modularity in Fedora 38 and older to provide multiple versions. The cri-o and cri-tools package maintainers will adopt a similar versioned approach to packaging and release in Fedora.

Release engineering: #Releng issue number

Release engineering would need to create the new dist-git repository for each new Kubernetes release.

Policies and guidelines: N/A (not needed for this Change)

Trademark approval: N/A (not needed for this Change)

Alignment with Community Initiatives:

Upgrade/compatibility impact

This change will require documentation in on-line Fedora documentation such as the dedicated Quick Docs page and posts to various forums and mailing lists to raise awareness. Upgrading to Fedora 40 on a machine with Fedora 39 or Fedora 38 would require a manual step by the user to select the appropriate versioned Kubernetes package.

How To Test

1. Install a versioned Kubernetes package on a fresh instance of Fedora and create a functioning test cluster. 2. On a cluster node, replace a non-versioned Kubernetes package with a versioned package and rejoin cluster. There should not be any errors.

User Experience

The user experience should remain unchanged except for the need to select a specific version of Kubernetes.

Dependencies

No direct dependencies. If cri-o and/or cri-tools are installed and used then these packages and kubernetes should have the same major:minor version.

Contingency Plan

Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
Contingency deadline: N/A (not a System Wide Change)
Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

Fedora Quick Docs: https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/

N/A (not a System Wide Change)

Release Notes

@@ Line 2: / Line 2: @@
 = Multiple Versioned Kubernetes Packages =
-{{Change_Proposal_Banner}}
 == Summary ==
-Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate release of Kubernetes for each Fedora release.
+Provide all maintained Kubernetes releases in Fedora as multiple, versioned packages. Current practice is a separate Kubernetes release matched with each Fedora release.
-This proposal is independent from https://fedoraproject.org/wiki/Changes/RestructureKubernetesPackages.
 == Owner ==
@@ Line 18: / Line 14: @@
 == Current status ==
-[[Category:ChangePageIncomplete]]
+[[Category:ChangeAcceptedF41]]
 <!-- When your change proposal page is completed and ready for review and announcement -->
 <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
@@ Line 27: / Line 23: @@
 [[Category:SelfContainedChange]]
-* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f40/ Fedora Linux 40]
+* Targeted release: [https://docs.fedoraproject.org/en-US/releases/f41/ Fedora Linux 41]
 * Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
 <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
@@ Line 35: / Line 31: @@
 ON_QA -> change is fully code complete
 -->
-* [<will be assigned by the Wrangler> devel thread]
+* [https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/KIS6TMQVFOJIPOWQIMW4HXDMV62W5PXT/ Announced]
-* FESCo issue: <will be assigned by the Wrangler>
+* [https://discussion.fedoraproject.org/t/f41-change-proposal-versioned-kubernetes-packages-self-contained/109579 Discussion Thread]
-* Tracker bug: <will be assigned by the Wrangler>
+* FESCo issue: [https://pagure.io/fesco/issue/3194 #3194]
-* Release notes tracker: <will be assigned by the Wrangler>
+* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2276440 #2276440]
+* Release notes tracker: [https://gitlab.com/fedora/docs/fedora-linux-documentation/release-notes/-/issues/139 #139]
+== Detailed Description ==
+The Kubernetes project maintains 3 concurrent versions with a new release every 4 months. Each version has a defined life-cycle of approximately 1 year (https://https://kubernetes.io/releases/ for details and current versions). In this proposal a release is a major:minor version combination such as 1.28 or 1.27 and ignores any patch updates (e.g. 1.28.1 or 1.28.2 as these are part of the same 1.28 minor release).
-== Detailed Description ==
+We currently match one version of Kubernetes with each Fedora release. See https://src.fedoraproject.org/rpms/kubernetes for the list of Kubernetes releases by Fedora release. Due to the differing release cadences between Fedora and Kubernetes this means that a new release of Fedora may not have the most current release of Kubernetes. And, given that the Kubernetes cluster upgrade process does not permit skipping major:minor releases, not providing a Kubernetes release in Fedora so that the most current Kubernetes release is available when a Fedora release goes into production becomes a barrier to using Fedora as a host OS for Kubernetes.
-The Kubernetes project maintains 3 concurrent versions. Each version has a defined life-cycle of approximately 1 year (https://https://kubernetes.io/releases/ for details and current versions). We currently match one release of Kubernetes with each Fedora release. See https://src.fedoraproject.org/rpms/kubernetes for the list of Kubernetes releases by Fedora release. Due to the differing release cadences between Fedora and Kubernetes this means that a new release of Fedora may not have the most current release of Kubernetes. And, given that the Kubernetes cluster upgrade process does not permit skipping major:minor releases, not providing a Kubernetes release in Fedora so that the most current Kubernetes release is available when a Fedora release goes into production becomes a barrier to using Fedora as a host OS for Kubernetes.
+We propose to create packages for all current Kubernetes releases for each Fedora release starting with Fedora 40. The package name would follow the Fedora naming convention standard for multiple package versions of "kubernetes[major].[minor]". Using the kubernetes-client rpm as an example, instead of kubernetes-client-1.29.2-1.fc41 Fedora would offer kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41, and kubernetes1.27-client-1.27.8-1.fc41. The exact list of Kubernetes versions available will depend on what is supported upstream.
-We propose to create packages for all current Kubernetes releases for each Fedora release starting with Fedora 40. The package name would follow the Fedora standard of kubernetes[major].[minor] naming convention. Using the kubernetes-node rpm as an example, instead of kubernetes-node-1.28.2-1.fc40 Fedora would offer kubernetes1.28-node-1.28.2-1.fc40, kubernetes1.27-node-1.27.5-1.fc40, and kubernetes1.26-node-1.26.8-1.fc40. The exact list of Kubernetes versions available will depend on what is supported upstream.
+We also propose that there not be any default version of Kubernetes for a given Fedora release. Fedora would not provide a kubernetes-client-1.30.1-1.fc41 package available, assuming that Kubernetes 1.30 is the "default" for Fedora 41. Default versions coupled to a given Fedora release can result in unplanned version updates to the installed Kubernetes version (i.e. v1.28 to v1.29) which can adversely affect cluster functioning.
-The Kubernetes release is built with a specific version of the Go language. The version of Go in a specific Fedora release will potentially be a constraint on which releases of Kubernetes can be provided for an older Fedora release.
+It is also important to note that each Kubernetes release is built with a specific version of the Go language. The version of Go available in a Fedora release will potentially be a constraint on which version of Kubernetes can be provided for an older Fedora release.
-We will also maintain a Kubernetes page on Fedora Quick Docs with information about the change and how to install Kubernetes using Fedora provided packages.
+We also maintain a Kubernetes page on Fedora Quick Docs with information about the change and how to install Kubernetes using Fedora provided packages.
 == Feedback ==
@@ Line 54: / Line 54: @@
 == Benefit to Fedora ==
-Fedora becomes a first class platform for Kubernetes using packages from Fedora repositories. That is, all current, maintained releases of Kubernetes are available in the main Fedora repositories. This allows Fedora as a host OS for a Kubernetes cluster to be maintained and upgraded independently of the Kubernetes release used by the cluster. This also allows the cluster to be upgraded independently of the Fedora release using Fedora provided packages.
+Fedora becomes a first class platform for Kubernetes using packages from Fedora repositories. That is, all current, maintained releases of Kubernetes are available in the main Fedora repositories, subject to the Go language constraint. This allows Fedora, as a host OS for a Kubernetes cluster, to be maintained and upgraded independently of the Kubernetes release used by the cluster. This also allows the cluster to be upgraded independently of the Fedora release using Fedora provided packages.
-This also means that a Kubernetes cluster administrator using Fedora as their workstation can install and use or retain the appropriate Kubernetes command line client that matches the release of the cluster. Updating to a new Fedora release will not inadvertently install a command line client that is not compatible with the release version of the cluster(s) managed by the user.
+This also means that a Kubernetes cluster administrator using Fedora as their workstation can install and use or retain the appropriate Kubernetes command line client, kubectl, that matches the release of the cluster. Updating to a new Fedora release will not inadvertently install a command line client that is not compatible with the release version of the cluster(s) managed by the user.
 <!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
@@ Line 89: / Line 88: @@
 == Scope ==
 * Proposal owners:
-<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+With each new minor release of Kubernetes, package owners would request a new repository on src.fedoraproject.org from engineering similar to what the nodejs team now does for the parallel-installable versions of nodejs. Documentation would be refreshed to inform users of the new version and what specific Fedora releases the new version of Kubernetes would be available on.
 * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
+Releases of cri-o and cri-tools are version matched with Kubernetes release at the major:minor level. Cri-o uses modularity in Fedora 38 and older to provide multiple versions. The cri-o and cri-tools package maintainers will adopt a similar versioned approach to packaging and release in Fedora.
 * Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
-<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.
+Release engineering would need to create the new dist-git repository for each new Kubernetes release.
-The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
 * Policies and guidelines: N/A (not needed for this Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
@@ Line 108: / Line 106: @@
 == Upgrade/compatibility impact ==
-<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
+This change will require documentation in on-line Fedora documentation such as the dedicated Quick Docs page and posts to various forums and mailing lists to raise awareness. Upgrading to Fedora 40 on a machine with Fedora 39 or Fedora 38 would require a manual step by the user to select the appropriate versioned Kubernetes package.
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
+== How To Test ==
+. Install a versioned Kubernetes package on a fresh instance of Fedora and create a functioning test cluster.
+. On a cluster node, replace a non-versioned Kubernetes package with a versioned package and rejoin cluster. There should not be any errors.
-== How To Test ==
 <!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
@@ Line 132: / Line 133: @@
 == User Experience ==
+The user experience should remain unchanged except for the need to select a specific version of Kubernetes.
 <!-- If this change proposal is noticeable by users, how will their experiences change as a result?
@@ Line 144: / Line 148: @@
 == Dependencies ==
-<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
+No direct dependencies. If cri-o and/or cri-tools are installed and used then these packages and kubernetes should have the same major:minor version.
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 == Contingency Plan ==
@@ Line 161: / Line 164: @@
 == Documentation ==
 <!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
+Fedora Quick Docs: https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/
 <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Search

Changes/VersionedKubernetesPackages: Difference between revisions