Merge pull request #397 from syedriko/syedriko-ols-1850

OLS-1850: OCP docs and Python deps update, week of 2025/06/16

Author: openshift-merge-bot[bot]

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.txt

@@ -209,9 +209,18 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+
+See the following example:
+
+```terminal
+[default]
+aws_access_key_id=<AWS_ACCESS_KEY_ID>
+aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
+```
+
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-azure.txt

@@ -84,9 +84,22 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+
+See the following example:
+
+```terminal
+AZURE_SUBSCRIPTION_ID= <azure_subscription_id>
+AZURE_TENANT_ID=<azure_tenant_id>
+AZURE_CLIENT_ID=<azure_client_id>
+AZURE_CLIENT_SECRET=<azure_client_secret>
+AZURE_STORAGE_ACCOUNT_ACCESS_KEY=<azure_storage_account_access_key>
+AZURE_RESOURCE_GROUP=<azure_resource_group>
+AZURE_CLOUD_NAME=<azure_cloud_name>
+```
+
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-gcp.txt

@@ -170,9 +170,9 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ibm-cloud.txt

@@ -139,9 +139,9 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-mcg.txt

@@ -99,9 +99,18 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+
+See the following example:
+
+```terminal
+[default]
+aws_access_key_id=<AWS_ACCESS_KEY_ID>
+aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
+```
+
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-ocs.txt

@@ -74,9 +74,18 @@ If you do not want to use the backup location credentials during the installatio
 
 * Your object storage and cloud storage, if any, must use the same credentials.
 * You must configure object storage for Velero.
-* You must create a credentials-velero file for the object storage in the appropriate format.
 
-* Create a Secret with the default name:
+1. Create a credentials-velero file for the backup storage location in the appropriate format for your cloud provider.
+
+See the following example:
+
+```terminal
+[default]
+aws_access_key_id=<AWS_ACCESS_KEY_ID>
+aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
+```
+
+2. Create a Secret custom resource (CR) with the default name:
 
 ```terminal
 $ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/oadp-3scale/backing-up-3scale-api-management-by-using-oadp.txt

@@ -387,7 +387,7 @@ The value of the metadata.name parameter in the backup is the same value used in
 $ oc create -f redis-backup.yaml
 ```
 
-Example output:
+Example output
 
 ```terminal
 backup.velero.io/redis-backup created
@@ -400,7 +400,7 @@ backup.velero.io/redis-backup created
 $ oc get backups.velero.io redis-backup -o yaml
 ```
 
-Example output:
+Example output
 
 ```terminal
 status:

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/oadp-3scale/restoring-3scale-api-management-by-using-oadp.txt

@@ -212,7 +212,7 @@ Do not delete the default PV and PVC associated with the database. If you do, yo
 $ oc scale deployment threescale-operator-controller-manager-v2 --replicas=0 -n threescale
 ```
 
-Example output:
+Example output
 
 ```terminal
 deployment.apps/threescale-operator-controller-manager-v2 scaled
@@ -238,7 +238,7 @@ done
 $ ./scaledowndeployment.sh
 ```
 
-Example output:
+Example output
 
 ```terminal
 deployment.apps.openshift.io/apicast-production scaled
@@ -264,7 +264,7 @@ deployment.apps.openshift.io/zync-que scaled
 $ oc delete deployment system-mysql -n threescale
 ```
 
-Example output:
+Example output
 
 ```terminal
 Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
@@ -335,7 +335,7 @@ restore.velerio.io/restore-mysql created
 $ oc get podvolumerestores.velero.io -n openshift-adp
 ```
 
-Example output:
+Example output
 
 ```terminal
 NAME                    NAMESPACE    POD                     UPLOADER TYPE   VOLUME                  STATUS      TOTALBYTES   BYTESDONE   AGE
@@ -349,7 +349,7 @@ restore-mysql-z7x7l     threescale   system-mysql-2-kjkhl    kopia           exa
 $ oc get pvc -n threescale
 ```
 
-Example output:
+Example output
 
 ```terminal
 NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   VOLUMEATTRIBUTESCLASS   AGE
@@ -374,7 +374,7 @@ You can restore the back-end Redis database by deleting the deployment and speci
 $ oc delete deployment backend-redis -n threescale
 ```
 
-Example output:
+Example output
 
 ```terminal
 Warning: apps.openshift.io/v1 deployment is deprecated in v4.14+, unavailable in v4.10000+
@@ -489,7 +489,7 @@ done
 $ ./scaledeployment.sh
 ```
 
-Example output:
+Example output
 
 ```terminal
 deployment.apps.openshift.io/apicast-production scaled

ocp-product-docs-plaintext/4.15/backup_and_restore/application_backup_and_restore/oadp-use-cases/oadp-usecase-backup-using-odf.txt

@@ -7,7 +7,7 @@ Following is a use case for using OADP and ODF to back up an application.
 
 In this use case, you back up an application by using OADP and store the backup in an object storage provided by Red Hat OpenShift Data Foundation (ODF).
 
-* You create a object bucket claim (OBC) to configure the backup storage location. You use ODF to configure an Amazon S3-compatible object storage bucket. ODF provides MultiCloud Object Gateway (NooBaa MCG) and Ceph Object Gateway, also known as RADOS Gateway (RGW), object storage service. In this use case, you use NooBaa MCG as the backup storage location.
+* You create an object bucket claim (OBC) to configure the backup storage location. You use ODF to configure an Amazon S3-compatible object storage bucket. ODF provides MultiCloud Object Gateway (NooBaa MCG) and Ceph Object Gateway, also known as RADOS Gateway (RGW), object storage service. In this use case, you use NooBaa MCG as the backup storage location.
 * You use the NooBaa MCG service with OADP by using the aws provider plugin.
 * You configure the Data Protection Application (DPA) with the backup storage location (BSL).
 * You create a backup custom resource (CR) and specify the application namespace to back up.

ocp-product-docs-plaintext/4.15/cicd/jenkins/important-changes-to-openshift-jenkins-images.txt

@@ -15,11 +15,11 @@ Red Hat OpenShift Container Platform 4.11 makes significant changes to the locat
 * If you upgrade from Red Hat OpenShift Container Platform 4.10 and earlier to 4.11, the deprecated maven and nodejs pod templates are still in the default image configuration.
 * If you upgrade from Red Hat OpenShift Container Platform 4.10 and earlier to 4.11, the jenkins-agent-maven and jenkins-agent-nodejs image streams still exist in your cluster. To maintain these image streams, see the following section, "What happens with the jenkins-agent-maven and jenkins-agent-nodejs image streams in the openshift namespace?"
 
-Each new image in the ocp-tools-4 repository in the registry.redhat.io registry supports multiple versions of Red Hat OpenShift Container Platform. When Red Hat updates one of these new images, it is simultaneously available for all versions. This availability is ideal when Red Hat updates an image in response to a security advisory. Initially, this change applies to Red Hat OpenShift Container Platform 4.11 and later. It is planned that this change will eventually apply to Red Hat OpenShift Container Platform 4.9 and later.
+Each new image in the ocp-tools-4 repository in the registry.redhat.io registry supports multiple versions of Red Hat OpenShift Container Platform. When Red Hat updates one of these new images, it is simultaneously available for all versions. This availability is ideal when Red Hat updates an image in response to a security advisory. Initially, this change applies to Red Hat OpenShift Container Platform 4.11 and later. It is planned that this change will eventually apply to Red Hat OpenShift Container Platform 4.9 and later.
 
-Previously, each Jenkins image supported only one version of Red Hat OpenShift Container Platform and Red Hat might update those images sequentially over time.
+Previously, each Jenkins image supported only one version of Red Hat OpenShift Container Platform and Red Hat might update those images sequentially over time.
 
-By moving from an in-payload image stream to an image stream that references non-payload images, Red Hat OpenShift Container Platform can define additional image stream tags. Red Hat has created a series of new image stream tags to go along with the existing "value": "jenkins:2" and "value": "image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest" image stream tags present in Red Hat OpenShift Container Platform 4.10 and earlier. These new image stream tags address some requests to improve how the Jenkins-related image streams are maintained.
+By moving from an in-payload image stream to an image stream that references non-payload images, Red Hat OpenShift Container Platform can define additional image stream tags. Red Hat has created a series of new image stream tags to go along with the existing "value": "jenkins:2" and "value": "image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest" image stream tags present in Red Hat OpenShift Container Platform 4.10 and earlier. These new image stream tags address some requests to improve how the Jenkins-related image streams are maintained.
 
 About the new image stream tags:
 
@@ -43,6 +43,34 @@ $ oc import-image jenkins-agent-maven -n openshift
 ```
 
 
+Jenkins supports the following architectures across Red Hat OpenShift Container Platform releases:
+
+* amd64
+* arm64
+* ppc64le
+* s390x
+
+However, for Red Hat OpenShift Container Platform Extended Update Support (EUS) releases, only the amd64 architecture is officially supported. As a result, OpenShift Jenkins images are shipped exclusively for amd64 on these releases. This is because the Red Hat OpenShift Container Platform platform itself supports only the amd64 architecture for EUS releases. For more information, see Support Matrix for OpenShift Jenkins releases.
+
+Yes, Jenkins container images are updated on a quarterly basis, and the updates are made available for all supported Jenkins images across all supported Red Hat OpenShift Container Platform releases.
+
+Red Hat supports only the latest Long-Term Support (LTS) version of the Jenkins core, as provided in our latest container images. We do not support multiple core versions. Our policy is to align with the latest Jenkins LTS version released by the upstream community.
+
+Yes. Our goal is to maintain platform alignment. This means that Jenkins controller and agent images are built and tested for each supported Red Hat OpenShift Container Platform releases.
+
+Jenkins is no longer part of the Red Hat OpenShift Container Platform core payload. Releases are managed separately. However, our intent is to publish updated OpenShift Jenkins images for newly released Red Hat OpenShift Container Platform releases within a few weeks of the Red Hat OpenShift Container Platform GA release.
+
+Yes. We align with the Jenkins upstream lifecycle and follow the LTS version. Red Hat typically ships OpenShift Jenkins image updates quarterly unless a critical fix requires an out-of-cycle release.
+
+To verify the current Jenkins LTS version:
+- Navigate to the Jenkins Catalog → Packages section
+- Search for “Jenkins”
+- The result will show two packages, one of which is the Jenkins LTS package.
+
+* Jenkins versions older than the current OpenShift Jenkins LTS are not supported.
+* Running Jenkins outside of Red Hat OpenShift Container Platform is not supported.
+* Multiple core versions of Jenkins are not supported. Plugins bundled with our OpenShift Jenkins images follow the same versioning across all supported Red Hat OpenShift Container Platform releases.
+
 # Customizing the Jenkins image stream tag
 
 To override the default upgrade behavior and control how the Jenkins image is upgraded, you set the image stream tag value that your Jenkins deployment configurations use.