Merge pull request #424 from syedriko/syedriko-ols-1874

OLS-1874: OCP docs and Python deps update, week of 2025/06/30

Author: openshift-merge-bot[bot]

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

@@ -137,21 +137,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.6 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.6 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 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.6 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.6 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.
 
 ## 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.6 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.6 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.
 
 ### 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-release-notes-1-3.txt

@@ -3,6 +3,20 @@
 
 The release notes for OpenShift API for Data Protection (OADP) 1.3 describe new features and enhancements, deprecated features, product recommendations, known issues, and resolved issues.
 
+# OADP 1.3.7 release notes
+
+OpenShift API for Data Protection (OADP) 1.3.7 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.3.6.
+
+The following Common Vulnerabilities and Exposures (CVEs) have been fixed in OADP 1.3.7
+
+* CVE-2024-45338
+* CVE-2025-22868
+* CVE-2025-30204
+
+## New features
+
+You can collect logs and information about 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 must-gather logs clusters directory. OADP-5384
+
 # OADP 1.3.6 release notes
 
 OpenShift API for Data Protection (OADP) 1.3.6 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.3.5.

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

@@ -1,106 +1,86 @@
 # Using the must-gather tool
 
 
-You can collect logs, metrics, and information about OADP custom resources by using the must-gather tool. The must-gather data must be attached to all customer cases.
-You can run the must-gather tool with the following data collection options:
-* Full must-gather data collection collects Prometheus metrics, pod logs, and Velero CR information for all namespaces where the OADP Operator is installed.
-* Essential must-gather data collection collects pod logs and Velero CR information for a specific duration of time, for example, one hour or 24 hours. Prometheus metrics and duplicate logs are not included.
-* must-gather data collection with timeout. Data collection can take a long time if there are many failed Backup CRs. You can improve performance by setting a timeout value.
-* Prometheus metrics data dump downloads an archive file containing the metrics data collected by Prometheus.
+You can collect logs and information about OADP custom resources by using the must-gather tool. The must-gather data must be attached to all customer cases.
+The must-gather tool is a container and does not run all the time. The tool runs for a few minutes only after you invoke the tool by running the must-gather command.
+
+# Using the must-gather tool
+
+You can run the must-gather tool with the following options. To use an option, you can add a flag corresponding to that option in the must-gather command.
+
+Default configuration:: This configuration collects pod logs, OADP and Velero custom resource (CR) information for all namespaces where the OADP Operator is installed.
+Timeout:: Data collection can take a long time if there are many failed Backup CRs. You can improve performance by setting a timeout value.
+Insecure TLS connections:: If a custom CA certificate is used, use the must-gather tool with  insecure TLS connections.
+
+The must-gather tool generates a Markdown output file with the collected information. The Markdown file is located in a cluster directory.
+
 * You have logged in to the Red Hat OpenShift Container Platform cluster as a user with the cluster-admin role.
 * You have installed the OpenShift CLI (oc).
-* You must use Red Hat Enterprise Linux (RHEL) 9 with OADP 1.4.
+* You are using OADP 1.3 or 1.4.
+
 1. Navigate to the directory where you want to store the must-gather data.
 2. Run the oc adm must-gather command for one of the following data collection options:
-* For full must-gather data collection, including Prometheus metrics, run the following command:
+* To use the default configuration of the must-gather tool, run one of the following commands:
+* For OADP 1.3, run the following command:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3
 ```
 
-
-The data is saved as must-gather/must-gather.tar.gz. You can upload this file to a support case on the Red Hat Customer Portal.
-
-For essential must-gather data collection, without Prometheus metrics, for a specific time duration, run the following command:
+* 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_<time>_essential 1
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4
 ```
 
-Specify the time in hours. Allowed values are 1h, 6h, 24h, 72h, or all, for example, gather_1h_essential or gather_all_essential.
-* For must-gather data collection with timeout, run the following command:
+* To use the timeout flag with the must-gather tool, run one of the following commands:
+* For OADP 1.3, 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.3 -- /usr/bin/gather --request-timeout <timeout> 1
 ```
 
-Specify a timeout value in seconds.
-* For a Prometheus metrics data dump, run the following command:
+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_metrics_dump
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_with_timeout <timeout> 1
 ```
 
-
-This operation can take a long time. The data is saved as must-gather/metrics/prom_data.tar.gz.
-* Gathering cluster data
-
-# Using must-gather with insecure TLS connections
-
-If a custom CA certificate is used, the must-gather pod fails to grab the output for velero logs/describe. To use the must-gather tool with  insecure TLS connections, you can pass the gather_without_tls flag to the must-gather command.
-
-* Pass the gather_without_tls flag, with value set to true, to the must-gather tool by using the following command:
-1. For OADP 1.3, run the following command:
+Specify a timeout value in seconds.
+* 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:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls <true/false>
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather --skip-tls
 ```
 
-2. For OADP 1.4, run the following command:
+* 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 <true/false>
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_without_tls <value> 1
 ```
 
-
-By default, the flag value is set to false. Set the value to true to allow insecure TLS connections.
-
-# Combining options when using the must-gather tool
-
-Currently, it is not possible to combine must-gather scripts, for example specifying a timeout threshold while permitting insecure TLS connections. In some situations, you can get around this limitation by setting up internal variables on the must-gather command line, such as the following examples:
-
-* For OADP 1.3:
+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:
 
 ```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>
+$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather --request-timeout 15s --skip-tls=true 1
 ```
 
-* For OADP 1.4:
+By default, the --skip-tls flag value is false. Set the value to true to allow insecure TLS connections. 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 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>
+$ 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
 ```
 
+By default, the --skip-tls flag value is false. Set the value to true to allow insecure TLS connections. Specify a timeout value.
 
-In these examples, set the skip_tls variable before running the gather_with_timeout script. The result is a combination of gather_with_timeout and gather_without_tls.
-
-The only other variables that you can specify this way are the following:
-
-* logs_since, with a default value of 72h
-* request_timeout, with a default value of 0s
-
-If DataProtectionApplication custom resource (CR) is configured with s3Url and insecureSkipTLS: true, the CR does not collect the necessary logs because of a missing CA certificate. To collect those logs, run the must-gather command with the following option:
+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.
+Example markdown output of must-gather tool
+![must-gather markdown output]
 
-* For OADP 1.3:
-
-```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls true
-```
-
-* For OADP 1.4:
-
-```terminal
-$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.4 -- /usr/bin/gather_without_tls true
-```
+* Gathering cluster data

ocp-product-docs-plaintext/4.15/installing/installing_bare_metal/installing-bare-metal-network-customizations.txt

@@ -1162,6 +1162,11 @@ You can configure RHCOS during ISO and PXE installations by using the following
 * Ignition configs: Red Hat OpenShift Container Platform Ignition config files (*.ign) are specific to the type of node you are installing. You pass the location of a bootstrap, control plane, or compute node Ignition config file during the RHCOS installation so that it takes effect on first boot. In special cases, you can create a separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system after completing installation. This special Ignition config is consumed by the coreos-installer to be applied on first boot of the installed system. Do not provide the standard control plane and compute node Ignition configs to the live ISO directly.
 * coreos-installer: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways before first boot. In particular, you can run the coreos-installer command to identify various artifacts to include, work with disk partitions, and set up networking. In some cases, you can configure features on the live system and copy them to the installed system.
 
+[NOTE]
+----
+As of version 0.17.0-3, coreos-installer requires RHEL 9 or later to run the program. You can still use older versions of coreos-installer to customize RHCOS artifacts of newer Red Hat OpenShift Container Platform releases and install metal images to disk. You can download older versions of the coreos-installer binary from the coreos-installer image mirror page.
+----
+
 Whether to use an ISO or PXE install depends on your situation. A PXE install requires an available DHCP service and more preparation, but can make the installation process more automated. An ISO install is a more manual process and can be inconvenient if you are setting up more than a few machines.
 
 ## Installing RHCOS by using an ISO image

ocp-product-docs-plaintext/4.15/installing/installing_bare_metal/installing-bare-metal.txt

@@ -1151,6 +1151,11 @@ You can configure RHCOS during ISO and PXE installations by using the following
 * Ignition configs: Red Hat OpenShift Container Platform Ignition config files (*.ign) are specific to the type of node you are installing. You pass the location of a bootstrap, control plane, or compute node Ignition config file during the RHCOS installation so that it takes effect on first boot. In special cases, you can create a separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system after completing installation. This special Ignition config is consumed by the coreos-installer to be applied on first boot of the installed system. Do not provide the standard control plane and compute node Ignition configs to the live ISO directly.
 * coreos-installer: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways before first boot. In particular, you can run the coreos-installer command to identify various artifacts to include, work with disk partitions, and set up networking. In some cases, you can configure features on the live system and copy them to the installed system.
 
+[NOTE]
+----
+As of version 0.17.0-3, coreos-installer requires RHEL 9 or later to run the program. You can still use older versions of coreos-installer to customize RHCOS artifacts of newer Red Hat OpenShift Container Platform releases and install metal images to disk. You can download older versions of the coreos-installer binary from the coreos-installer image mirror page.
+----
+
 Whether to use an ISO or PXE install depends on your situation. A PXE install requires an available DHCP service and more preparation, but can make the installation process more automated. An ISO install is a more manual process and can be inconvenient if you are setting up more than a few machines.
 
 ## Installing RHCOS by using an ISO image