Revision as of 19:39, 17 August 2023

Kubernetes Package Name Changes

Summary

New or revised (sub)package names are proposed for the Kubernetes packages. The new names will better align Kubernetes with current usage as documented upstream and improve alignment of package content with current Fedora practices and standards.

Owner

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

Current status

Targeted release: Fedora Linux 40
Last updated: 2023-08-17
[<will be assigned by the Wrangler> devel thread]
FESCo issue: <will be assigned by the Wrangler>
Tracker bug: <will be assigned by the Wrangler>
Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

Kubernetes provides "Open Source Production-Grade Container Scheduling And Management".

The existing Kubernetes package and sub-packages are outlined in the table below. All packages include relevant configuration files and documentation (man pages).

Current package and sub-packages in the Kubernetes package
Name	Status	(Sub )Package Notes
Kubernetes	Main Package	Empty. Requires the Client sub-package.
Client	Sub-package	Kubectl - Command line client. Used to manage a cluster from any computer connected to network.
Kubeadm	Sub-package	Kubeadm - Administrative client. Used to join or remove a node to/from a cluster.
Master	Sub-package	Kubernetes services packaged as obsolete systemd services. Modern installations of Kubernetes install these services as static pods.
Node	Subpackage	Kubelet - Kubernetes runtime.

Proposed sub package names and associate content are in the table below.

Proposed package and sub-packages in the Kubernetes package
Name	Status	(Sub )Package Notes
Kubernetes	Main Package	Provides kubelet (runtime) and kuberadm (node administation) binaries and configuration files. Requires the Client sub-package.
Kubernetes-doc	Sub-package	Documentation (man pages) for kubectl and kubeadm.
Client	Sub-package	Kubectl - Command line client. Used to manage a cluster from any computer connected to network.
Client-doc	Sub-package	Documentation for kubectl, command line client.

With the proposed sub packages a user that wants to install Kubernetes on a Fedora machine will only need to install the kubernetes rpm and optionally the kubernetes.doc rpm. This action installs all 3 needed Kubernetes binaries and configuration files and aligns with guidance from upstream (i.e. install kubectl, kubeadm, and kubelet on each machine in a cluster).

Kubernetes cluster managers will install, as before, the kubernetes-client rpm on any machine used by the manager to manage a cluster. The kubernetes-client-doc rpm will be optional.

Feedback

Benefit to Fedora

The primary beneficiary will be Fedora users that want to install Kubernetes on a Fedora machine and use that machine as a node in a cluster or as a management console to manage one or more local or remote clusters. It will also segregate out documentation (man files) so that a minimal install can be done with just the needed executables and supporting configuration files. Installation of the kubernetes rpm is all that is needed to prepare a Fedora machine to participate as a node in a cluster. The current package structure requires the user to install either the kubernetes, kubernetes-kubeadm, and kubernetes-node rpms or install the kubernetes-client, kubernetes-kubeadm, and kubernetes-node rpms to obtain the same level of functionality.

Scope

Proposal owners:

Other developers:

Release engineering: #Releng issue number

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

How To Test

User Experience

Dependencies

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

N/A (not a System Wide Change)

Release Notes

@@ Line 77: / Line 77: @@
 == Benefit to Fedora ==
-<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
-      Be sure to include the following areas if relevant:
-      If this is a major capability update, what has changed?
-           For example: This change introduces Python 5 that runs without the Global Interpreter Lock and is fully multithreaded.
-      If this is a new functionality, what capabilities does it bring?
-           For example: This change allows package upgrades to be performed automatically and rolled-back at will.
-      Does this improve some specific package or set of packages?
-           For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies.
-      Does this improve specific Spins or Editions?
-           For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server.
-      Does this make the distribution more efficient?
-           For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end.
-      Is this an improvement to maintainer processes?
-           For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly.
-      Is this an improvement targeted as specific contributors?
-           For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors.
-     When a Change has multiple benefits, it's better to list them all.
+The primary beneficiary will be Fedora users that want to install Kubernetes on a Fedora machine and use that machine as a node in a cluster or as a management console to manage one or more local or remote clusters. It will also segregate out documentation (man files) so that a minimal install can be done with just the needed executables and supporting configuration files. Installation of the kubernetes rpm is all that is needed to prepare a Fedora machine to participate as a node in a cluster. The current package structure requires the user to install either the kubernetes, kubernetes-kubeadm, and kubernetes-node rpms or install the kubernetes-client, kubernetes-kubeadm, and kubernetes-node rpms to obtain the same level of functionality.
-     Consider these Change pages from previous editions as inspiration:
-     https://fedoraproject.org/wiki/Changes/Annobin (low-level and technical, invisible to users)
-     https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo (low-level, but visible to advanced users)
-     https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration (primarily a UX change)
-     https://fedoraproject.org/wiki/Changes/NoMoreAlpha (an improvement to distro processes)
-     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
--->
 == Scope ==

Search

Draft Kubernetes Package Name Change Proposal: Difference between revisions