Merge pull request #461 from syedriko/syedriko-ols-1976

OLS-1976: OCP docs update, week of 2025/07/28

Author: openshift-merge-bot[bot]

ocp-product-docs-plaintext/4.15/architecture/architecture-installation.txt

@@ -202,6 +202,10 @@ The Cluster Version Operator (CVO) in your cluster checks with the OpenShift Upd
 
 To allow the OpenShift Update Service to provide only compatible updates, a release verification pipeline drives automation. Each release artifact is verified for compatibility with supported cloud platforms and system architectures, as well as other component packages. After the pipeline confirms the suitability of a release, the OpenShift Update Service notifies you that it is available.
 
+The OpenShift Update Service (OSUS) supports a single-stream release model, where only one release version is active and supported at any given time. When a new release is deployed, it fully replaces the previous release.
+
+The updated release provides support for upgrades from all Red Hat OpenShift Container Platform versions starting after 4.8 up to the new release version.
+
 
 [IMPORTANT]
 ----

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/oadp-features-plugins.txt

@@ -138,21 +138,21 @@ OpenShift API for Data Protection (OADP) is platform neutral. The information th
 * OADP 1.1.7 was tested successfully against Red Hat OpenShift Container Platform 4.11 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.1.7 in terms of backup locations for these systems.
 * OADP 1.2.3 was tested successfully against Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.2.3 in terms of backup locations for these systems.
 * OADP 1.3.7 was tested successfully against Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.3.7 in terms of backup locations for these systems.
-* OADP 1.4.4 was tested successfully against Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.4.4 in terms of backup locations for these systems.
+* OADP 1.4.5 was tested successfully against Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17 for both IBM Power(R) and IBM Z(R). The sections that follow give testing and support information for OADP 1.4.5 in terms of backup locations for these systems.
 
 ## OADP support for target backup locations using IBM Power
 
 * IBM Power(R) running with Red Hat OpenShift Container Platform 4.11 and 4.12, and OpenShift API for Data Protection (OADP) 1.1.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with Red Hat OpenShift Container Platform 4.11 and 4.12, and OADP 1.1.7 against all S3 backup location targets, which are not AWS, as well.
 * IBM Power(R) running with Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and OADP 1.2.3 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with Red Hat OpenShift Container Platform 4.12, 4.13. 4.14, and 4.15, and OADP 1.2.3 against all S3 backup location targets, which are not AWS, as well.
 * IBM Power(R) running with Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and OADP 1.3.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with Red Hat OpenShift Container Platform 4.13, 4.14, and 4.15, and OADP 1.3.7 against all S3 backup location targets, which are not AWS, as well.
-* IBM Power(R) running with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.4 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.4 against all S3 backup location targets, which are not AWS, as well.
+* IBM Power(R) running with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.5 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Power(R) with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and OADP 1.4.5 against all S3 backup location targets, which are not AWS, as well.
 
 ## OADP testing and support for target backup locations using IBM Z
 
 * IBM Z(R) running with Red Hat OpenShift Container Platform 4.11 and 4.12, and OpenShift API for Data Protection (OADP) 1.1.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with Red Hat OpenShift Container Platform 4.11 and 4.12, and OADP 1.1.7 against all S3 backup location targets, which are not AWS, as well.
 * IBM Z(R) running with Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and OADP 1.2.3 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with Red Hat OpenShift Container Platform 4.12, 4.13, 4.14 and 4.15, and OADP 1.2.3 against all S3 backup location targets, which are not AWS, as well.
 * IBM Z(R) running with Red Hat OpenShift Container Platform 4.12, 4.13, 4.14, and 4.15, and 1.3.7 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with Red Hat OpenShift Container Platform 4.13 4.14, and 4.15, and 1.3.7 against all S3 backup location targets, which are not AWS, as well.
-* IBM Z(R) running with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.4 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.4 against all S3 backup location targets, which are not AWS, as well.
+* IBM Z(R) running with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.5 was tested successfully against an AWS S3 backup location target. Although the test involved only an AWS S3 target, Red Hat supports running IBM Z(R) with Red Hat OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17, and 1.4.5 against all S3 backup location targets, which are not AWS, as well.
 
 ### Known issue of OADP using IBM Power(R) and IBM Z(R) platforms
 

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-4-release-notes.txt

@@ -8,6 +8,26 @@ The release notes for OpenShift API for Data Protection (OADP) describe new feat
 For additional information about OADP, see OpenShift API for Data Protection (OADP) FAQs
 ----
 
+# OADP 1.4.5 release notes
+
+The OpenShift API for Data Protection (OADP) 1.4.5 release notes lists new features and resolved issues.
+
+## New features
+
+You can collect logs and information about OpenShift API for Data Protection (OADP) custom resources by using the must-gather tool. The must-gather data must be attached to all customer cases.
+This tool generates a Markdown output file with the collected information, which is located in the clusters directory of the must-gather logs.  (OADP-5904)
+
+## Resolved issues
+
+OADP 1.4.5 fixes the following CVEs:: 
+* CVE-2024-45337
+* CVE-2024-45338
+* CVE-2025-21613
+* CVE-2025-27144
+* CVE-2025-22868
+* CVE-2025-22869
+* CVE-2025-30204
+
 # OADP 1.4.4 release notes
 
 OpenShift API for Data Protection (OADP) 1.4.4 is a Container Grade Only (CGO) release, which is released to refresh the health grades of the containers. No code was changed in the product itself compared to that of OADP 1.4.3.

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/troubleshooting/oadp-monitoring.txt

@@ -16,6 +16,14 @@ With enabled User Workload Monitoring, it is possible to configure and use any P
 
 Monitoring metrics requires enabling monitoring for the user-defined projects and creating a ServiceMonitor resource to scrape those metrics from the already enabled OADP service endpoint that resides in the openshift-adp namespace.
 
+
+[NOTE]
+----
+The OADP support for Prometheus metrics is offered on a best-effort basis and is not fully supported.
+----
+
+For more information about setting up the monitoring stack, see Configuring user workload monitoring.
+
 * You have access to an Red Hat OpenShift Container Platform cluster using an account with cluster-admin permissions.
 * You have created a cluster monitoring config map.
 
@@ -29,10 +37,10 @@ $ oc edit configmap cluster-monitoring-config -n openshift-monitoring
 
 ```yaml
 apiVersion: v1
+kind: ConfigMap
 data:
   config.yaml: |
     enableUserWorkload: true 1
-kind: ConfigMap
 metadata:
 # ...
 ```
@@ -142,7 +150,7 @@ servicemonitor.monitoring.coreos.com/oadp-service-monitor created
 ```
 
 
-* Confirm that the new service monitor is in an Up state by using the Administrator perspective of the Red Hat OpenShift Container Platform web console:
+* Confirm that the new service monitor is in an Up state by using the Administrator perspective of the Red Hat OpenShift Container Platform web console. Wait a few minutes for the service monitor to reach the Up state.
 1. Navigate to the Observe -> Targets page.
 2. Ensure the Filter is unselected or that the User source is selected and type openshift-adp in the Text search field.
 3. Verify that the status for the Status for the service monitor is Up.
@@ -204,7 +212,7 @@ OADP backup failing alert
 
 # List of available metrics
 
-These are the list of metrics provided by the OADP together with their Types.
+Refer to the following table for a list of Velero metrics provided by OADP together with their Types:
 
 
 

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/troubleshooting/using-the-must-gather-tool.txt

@@ -44,10 +44,10 @@ Specify a timeout value.
 * For OADP 1.4, run the following command:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_with_timeout <timeout> 1
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather --request-timeout 1m 1
 ```
 
-Specify a timeout value in seconds.
+In this example, the timeout is 1 minute.
 * To use the insecure TLS connection flag with the must-gather tool, run one of the following commands:
 * For OADP 1.3, run the following command:
 
@@ -58,10 +58,9 @@ $ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
 * For OADP 1.4, run the following command:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_without_tls <value> 1
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather --skip-tls
 ```
 
-By default, the value is false. Set to true to allow insecure TLS connections.
 * To use a combination of the insecure TLS connection, and the timeout flags with the must-gather tool, run one of the following commands:
 * For OADP 1.3, run the following command:
 
@@ -73,10 +72,10 @@ By default, the --skip-tls flag value is false. Set the value to true to allow i
 * For OADP 1.4, run the following command:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 --skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds> 1
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather --request-timeout 15s --skip-tls 1
 ```
 
-By default, the --skip-tls flag value is false. Set the value to true to allow insecure TLS connections. Specify a timeout value.
+In this example, the timeout is 15 seconds. By default, the --skip-tls flag value is false. Set the value to true to allow insecure TLS connections.
 
 1. Verify that the Markdown output file is generated at the following location: must-gather.local.89&#8230;&#8203;054550/registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.5-sha256-0&#8230;&#8203;84/clusters/a4&#8230;&#8203;86/oadp-must-gather-summary.md
 2. Review the must-gather data in the Markdown file by opening the file in a Markdown previewer. For an example output, refer to the following image. You can upload this output file to a support case on the Red Hat Customer Portal.

ocp-product-docs-plaintext/4.15/installing/installing_with_agent_based_installer/installing-with-agent-based-installer.txt

@@ -337,6 +337,13 @@ $ cd ../mirror
 
 As an optional task, you can use this procedure to encrypt your disk or partition while installing Red Hat OpenShift Container Platform with the Agent-based Installer.
 
+
+[IMPORTANT]
+----
+If there are leftover TPM encryption keys from a previous operating system on the bare-metal host, the cluster deployment can get stuck.
+To avoid this situation, it is highly recommended to reset the TPM chip in the BIOS before booting the ISO.
+----
+
 * You have created and configured the install-config.yaml and agent-config.yaml files, unless you are using ZTP manifests.
 * You have placed the openshift-install binary in a directory that is on your PATH.
 

ocp-product-docs-plaintext/4.15/networking/k8s_nmstate/k8s-nmstate-updating-node-network-config.txt

@@ -1170,6 +1170,5 @@ The next hop address for the node traffic. This must be in the same subnet as th
 
 [IMPORTANT]
 ----
-You cannot use the OVN-Kubernetes br-ex bridge as the next hop interface when configuring a static route unless you manually configured a customized br-ex bridge.
-For more information, see "Creating a manifest object that includes a customized br-ex bridge" in the Deploying installer-provisioned clusters on bare metal document or the Installing a user-provisioned cluster on bare metal document.
+You cannot use the OVN-Kubernetes br-ex bridge as the next hop interface when configuring a static route.
 ----

ocp-product-docs-plaintext/4.15/networking/ovn_kubernetes_network_provider/about-ovn-kubernetes.txt

@@ -53,6 +53,8 @@ Red Hat OpenShift Networking offers two options for the network plugin, OpenShif
 
 The OVN-Kubernetes network plugin has the following limitations:
 
+* If you set the ipv6.disable parameter to 1 in the kernelArgument section of the MachineConfig custom resource (CR) for your cluster, OVN-Kubernetes pods enter a CrashLoopBackOff state. Additionally, updating your cluster to a later version of Red Hat OpenShift Container Platform fails because the Network Operator is stuck on a Degraded state. Red Hat does not support disabling IPv6 adddresses for your cluster so do not set the ipv6.disable parameter to 1.
+
 * For clusters configured for dual-stack networking, both IPv4 and IPv6 traffic must use the same network interface as the default gateway.
 If this requirement is not met, pods on the host in the ovnkube-node daemon set enter the CrashLoopBackOff state.
 If you display a pod with a command such as oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml, the status field contains more than one message about the default gateway, as shown in the following output:

ocp-product-docs-plaintext/4.15/networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.txt

@@ -127,7 +127,7 @@ For more information, see Networking limits.
 
 ## Considerations for using an egress IP on additional network interfaces
 
-In Red Hat OpenShift Container Platform, egress IPs provide administrators a way to control network traffic. Egress IPs can be used with the br-ex, or primary, network interface, which is a Linux bridge interface associated with Open vSwitch, or they can be used with additional network interfaces.
+In Red Hat OpenShift Container Platform, egress IPs provide administrators a way to control network traffic. Egress IPs can be used with a br-ex Open vSwitch (OVS) bridge interface and any physical interface that has IP connectivity enabled.
 
 You can inspect your network interface type by running the following command:
 
@@ -155,24 +155,10 @@ OVN-Kubernetes provides a mechanism to control and direct outbound network traff
 
 For users who want an egress IP and traffic to be routed over a particular interface that is not the primary network interface, the following conditions must be met:
 
-* Red Hat OpenShift Container Platform is installed on a bare metal cluster. This feature is disabled within cloud or hypervisor environments.
+* Red Hat OpenShift Container Platform is installed on a bare-metal cluster. This feature is disabled within a cloud or a hypervisor environment.
 * Your Red Hat OpenShift Container Platform pods are not configured as host-networked.
-* If a network interface is removed or if the IP address and subnet mask which allows the egress IP to be hosted on the interface is removed, then the egress IP is reconfigured. Consequently, it could be assigned to another node and interface.
-* IP forwarding must be enabled for the network interface. To enable IP forwarding, you can use the oc edit network.operator command and edit the object like the following example:
-
-```yaml
-# ...
-spec:
-  clusterNetwork:
-  - cidr: 10.128.0.0/14
-    hostPrefix: 23
-  defaultNetwork:
-    ovnKubernetesConfig:
-      gatewayConfig:
-        ipForwarding: Global
-# ...
-```
-
+* If a network interface is removed or if the IP address and subnet mask which allows the egress IP to be hosted on the interface is removed, the egress IP is reconfigured. Consequently, the egress IP could be assigned to another node and interface.
+* If you use an Egress IP address on a secondary network interface card (NIC), you must use the Node Tuning Operator to enable IP forwarding on the secondary NIC.
 
 ## Assignment of egress IPs to pods