OSDOCS-15763:Update the z-stream RNs for 4.18.22

Author: Ted Avery

modules/microshift-con-understanding-generic-device-plugin.adoc

@@ -0,0 +1,29 @@
+// Module included in the following assemblies:
+//
+// microshift_install_bootc/microshift-gdp.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="microshift-con-understanding-generic-device-plugin_{context}"]
+The Generic Device Plugin (GDP) for MicroShift is a Kubernetes device plugin that enables applications running in pods to access host devices like serial ports, cameras, and FUSE devices securely. This capability is especially important for edge and IoT environments where direct hardware interaction is a common requirement. The GDP integrates with the Kubelet to advertise available devices to the cluster and facilitate their allocation to pods without requiring elevated privileges within the container itself.
+
+.Generic Devices vs. Specialized Devices
+The Generic Device Plugin is designed to handle devices that are initialized and managed by the operating system and do not require any special initialization procedures or drivers for a pod to use them.
+
+Here are examples of generic devices:
+* Serial ports (e.g., `/dev/ttyUSB*`, `/dev/ttyACM*`).
+* Video cameras (e.g., `/dev/video0`).
+* Sound devices (e.g., `/dev/snd`, `/dev/snd/controlC0`).
+* USB devices specified by Vendor ID and Product ID.
+
+The following devices are not suitable for the Generic Device Plugin:
+* Devices that require specific initialization procedures beyond standard OS management.
+* Specialized hardware that needs additional drivers or kernel modules. Examples include GPUs (Graphics Processing Units) and FPGAs (Field-Programmable Gate Arrays). These types of devices typically require their own specialized device plugins.
+
+.Understanding the Generic Device Plugin
+The Generic Device Plugin operates in the following manner:
+
+. **Registration**: The GDP starts and registers itself with the Kubelet on the MicroShift node.
+. **Device Reporting**: The Kubelet queries the GDP for available devices. The GDP responds by listing the generic devices configured in MicroShift's `config.yaml`.
+. **Device Request**: When a pod requests a generic device (for example, `device.microshift.io/serial: 1`) in its `resources.limits` section, the Kubelet instructs the GDP to prepare the requested device.
+. **Device Provisioning**: The GDP provides the Kubelet with the necessary information (for example, device path on the host). The Kubelet then uses this information to request the container runtime (CRI-O) to make the host device available inside the pod's container.
+. **Allocation Management**: The Kubelet maintains the state of device allocations and caches this information on disk, ensuring persistent access even if the device plugin restarts. The GDP itself primarily reports available devices and facilitates their setup; it does not manage the detailed bookkeeping of which specific device is attached to a particular pod.

modules/microshift-gdp.adoc

@@ -0,0 +1,25 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="microshift-gdp_{context}"]
+= About the Generic Device Plugin (GDP)
+include::_attributes/attributes-microshift.adoc[]
+:context: generic-device-plugin
+
+The Generic Device Plugin (GDP) for {microshift-short} enables your containerized applications to securely access physical host devices, such as serial ports and cameras directly from within Kubernetes pods. This is crucial for edge and IoT use cases where applications frequently need to interact with specialized hardware. 
+
+include::modules/microshift-con-understanding-generic-device-plugin.adoc[leveloffset=+1]
+
+include::modules/microshift-proc-configuring-generic-device-plugin.adoc[leveloffset=+2]
+
+include::modules/microshift-proc-deploying-workloads-with-generic-devices.adoc[leveloffset=+2]
+
+include::modules/microshift-ref-generic-device-plugin-configuration-parameters.adoc[leveloffset=+2]
+
+include::modules/microshift-con-limitations-of-generic-device-plugin.adoc[leveloffset=+2]
+
+[id="_additional-resources_microshift-cni_{context}"]
+== Additional resources
+
+* xref:../microshift_configuring/microshift-using-config-yaml.adoc#microshift-config-yaml_microshift-configuring[Using a YAML configuration file]
+* xref:../microshift_networking/microshift-networking-settings.adoc#microshift-understanding-networking-settings[Understanding networking settings]
+* xref:../microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc#microshift-cni-multus[About using multiple networks]
+* xref:../microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc#microshift-network-policies[About network policies]

release_notes/ocp-4-18-release-notes.adoc

@@ -3023,6 +3023,51 @@ This section will continue to be updated over time to provide notes on enhanceme
 For any {product-title} release, always review the instructions on xref:../updating/updating_a_cluster/updating-cluster-web-console.adoc#updating-cluster-web-console[updating your cluster] properly.
 ====
 
+// 4.18.22
+[id="ocp-4-18-22_{context}"]
+=== RHSA-2025:13325 - {product-title} {product-version}.22 bug fix and security update
+
+Issued: 13 August 2025
+
+{product-title} release {product-version}.22 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:13325[RHSA-2025:13325] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:13326[RHBA-2025:13326] advisory.
+
+Space precluded documenting all of the container images for this release in the advisory.
+
+You can view the container images in this release by running the following command:
+
+[source,terminal]
+----
+$ oc adm release info 4.18.22 --pullspecs
+----
+
+[id="ocp-4-18-22-bug-fixes_{context}"]
+==== Bug fixes
+
+* Before this update, destroying a cluster in the unsupported region `mx-central-1` caused the destroyer to fail to find a partition and not exit. As a consequence, you could not destroy a Red Hat OpenShift Container Platform cluster in the `mx-central-1`region due to constant error reporting. With this release, the destroyer does not report errors for the unsupported region `mx-central-1`, which enables the successful destruction of a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-49749[OCPBUGS-49749])
+
+* Before this update, destroying a cluster in the unsupported region `mx-central-1` caused the destroyer to fail to find a partition and not exit. As a consequence, you could not destroy a Red Hat OpenShift Container Platform cluster in the `mx-central-1`region due to constant error reporting. With this release, the destroyer does not report errors for the unsupported region `mx-central-1`, which enables the successful destruction of a cluster. (link:https://issues.redhat.com/browse/OCPBUGS-56177[OCPBUGS-56177])
+
+* Before this update, combined specification and status updates lists triggered unnecessary firmware upgrades, which caused system downtime. With this release, a firmware upgrade optimization skips unnecessary firmware upgrades. (link:https://issues.redhat.com/browse/OCPBUGS-56766[OCPBUGS-56766])
+
+* Before this update, the `console-telemetry` plugin received a `Forbidden` error due to using the wrong API endpoint for tracking usage. As a consequence, the `Forbidden error in console-telemetry-plugin usage tracking` error occurred. With this release, the `console-telemetry` plugin posts usage data to `/api/metrics/usage` instead of `/metrics/usage`. As a result, the `console-telemetry`plugin does not receive a `Forbidden` error, which ensures accurate usage tracking. (link:https://issues.redhat.com/browse/OCPBUGS-58364[OCPBUGS-58364])
+
+* Before this update, the installer failed when {aws-first} credentials were not found and the survey was attempting to list all {aws-short} regions preventing users from creating the install-config. With this release, the installer no longer fails when {aws-short} credentials are not set, allow users to input them during the survey. (link:https://issues.redhat.com/browse/OCPBUGS-59155[OCPBUGS-59155])
+
+* Before this update, when a `HostedCluster` was configured with a proxy URL such as http://user:pass@host, the authentication header was not getting forwarded by the konnectivity proxy to the user proxy, failing authentication. With this release, the proper authentication header is sent when a user and password is specified in the proxy URL. (link:https://issues.redhat.com/browse/OCPBUGS-59503[OCPBUGS-59503])
+
+* Before this update, the upgrade to 4.18.15 introduced stale Network Address Translation (NAT) handling for egress IPs, which led to duplicate NAT's and hosts with the same egress IP allocation. As a consequence, egress IP allocation became inconsistent and unreliable, which caused traffic flow disruptions. With this release, the egress IP controller removes stale NAT and Source Network Address Translation (SNAT) rules for deleted nodes and pods. As a result, egress IP allocation is reliable and consistent. (link:https://issues.redhat.com/browse/OCPBUGS-59531[OCPBUGS-59531])
+
+* Before this update, the `oc-mirror`did not detect Helm Chart images that used an aliased sub-chart. As a consequence, the Helm Chart images were missing after mirroring. With this release, the `oc-mirror`detects and mirrors Helm Chart images with an aliased sub-chart. (link:https://issues.redhat.com/browse/OCPBUGS-59798[OCPBUGS-59798])
+
+* Before this update, when you cloned a .tar file with zero length, the `oc-mirror` ran indefinitely due to an empty archive file. As a consequence, no progress occurred when you mirrored a 0-byte .tar file. With this release, 0-byte tar files are detected and reported as errors, which prevents the `oc-mirror` from hanging. (link:https://issues.redhat.com/browse/OCPBUGS-59864[OCPBUGS-59864])
+
+* Before this update, in multi-zone clusters with only a single worker per zone, if the Monitoring Operator's Prometheus pods were scheduled to nodes that reboot back-to-back and both reboots took longer than 15 minutes to return to service, the Monitoring Operator might have degraded. With this release, the time-out has been extended to 20 minutes to prevent the Monitoring Operator from entering a degraded state on common cluster topologies. Clusters where the two nodes with Prometheus pods reboot back-to-back and take more than 20 minutes might still report a degraded state until the second node and Prometheus pod return to a normal state.(link:https://issues.redhat.com/browse/OCPBUGS-59962[OCPBUGS-59962])
+
+
+[id="ocp-4-18-22-updating_{context}"]
+==== Updating
+To update an {product-title} 4.18 cluster to this latest release, see xref:../updating/updating_a_cluster/updating-cluster-cli.adoc#updating-cluster-cli[Updating a cluster using the CLI].
+
 // 4.18.21
 [id="ocp-4-18-21_{context}"]
 === RHSA-2025:11677 - {product-title} {product-version}.21 bug fix and security update