OADP-7028: Prepare OADP 1.5 RNs for DITA

vashirova · vashirova · commit 425197f70bfd · 2025-12-17T10:40:42.000+01:00
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -3675,6 +3675,8 @@ Topics:
     Topics:
     - Name: OADP 1.5 release notes
       File: oadp-1-5-release-notes
+    - Name: Upgrading OADP 1.4 to 1.5
+      File: oadp-upgrade-notes-1-5
     - Name: OADP 1.4 release notes
       File: oadp-1-4-release-notes
   - Name: OADP performance
diff --git a/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-5-release-notes.adoc b/backup_and_restore/application_backup_and_restore/release-notes/oadp-1-5-release-notes.adoc
@@ -9,11 +9,11 @@ include::_attributes/attributes-openshift-dedicated.adoc[]
 toc::[]
 
 [role="_abstract"]
-The release notes for {oadp-first} describe new features and enhancements, deprecated features, product recommendations, known issues, and resolved issues.
+The release notes for {oadp-first} 1.5 describe new features and enhancements, deprecated features, product recommendations, known issues, and resolved issues.
 
 [NOTE]
 ====
-For additional information about {oadp-short}, see link:https://access.redhat.com/articles/5456281[{oadp-first} FAQs]
+For additional information about {oadp-short}, see link:https://access.redhat.com/articles/5456281[{oadp-first} FAQ].
 ====
 
 include::modules/oadp-1-5-3-release-notes.adoc[leveloffset=+1]
@@ -23,17 +23,3 @@ include::modules/oadp-1-5-2-release-notes.adoc[leveloffset=+1]
 include::modules/oadp-1-5-1-release-notes.adoc[leveloffset=+1]
 
 include::modules/oadp-1-5-0-release-notes.adoc[leveloffset=+1]
-
-[id="upgrade-notes-1-5_{context}"]
-== Upgrading OADP 1.4 to 1.5
-
-[NOTE]
-====
-Always upgrade to the next minor version. Do not skip versions. To update to a later version, upgrade only one channel at a time. For example, to upgrade from {oadp-short} 1.1 to 1.3, upgrade first to 1.2, and then to 1.3.
-====
-
-include::modules/changes-from-oadp-1-4-to-1-5.adoc[leveloffset=+2]
-include::modules/oadp-backing-up-dpa-configuration-1-5-0.adoc[leveloffset=+2]
-include::modules/oadp-upgrading-oadp-operator-1-5-0.adoc[leveloffset=+2]
-include::modules/converting-dpa-to-the-new-version-for-oadp-1-5-0.adoc[leveloffset=+2]
-include::modules/oadp-verifying-upgrade-1-5-0.adoc[leveloffset=+2]
diff --git a/backup_and_restore/application_backup_and_restore/release-notes/oadp-upgrade-notes-1-5.adoc b/backup_and_restore/application_backup_and_restore/release-notes/oadp-upgrade-notes-1-5.adoc
@@ -0,0 +1,27 @@
+:_mod-docs-content-type: ASSEMBLY
+
+[id="upgrade-notes-1-5_{context}"]
+= Upgrading OADP 1.4 to 1.5
+include::_attributes/common-attributes.adoc[]
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: oadp-upgrade-notes-1-5
+
+toc::[]
+
+[role="_abstract"]
+Learn how to upgrade your existing {oadp-short} 1.4 installation to {oadp-short} 1.5.
+
+[NOTE]
+====
+Always upgrade to the next minor version. Do not skip versions. To update to a later version, upgrade only one channel at a time. For example, to upgrade from {oadp-short} 1.1 to 1.3, upgrade first to 1.2, and then to 1.3.
+====
+
+include::modules/changes-from-oadp-1-4-to-1-5.adoc[leveloffset=+1]
+
+include::modules/oadp-backing-up-dpa-configuration-1-5-0.adoc[leveloffset=+1]
+
+include::modules/oadp-upgrading-oadp-operator-1-5-0.adoc[leveloffset=+1]
+
+include::modules/converting-dpa-to-the-new-version-for-oadp-1-5-0.adoc[leveloffset=+1]
+
+include::modules/oadp-verifying-upgrade-1-5-0.adoc[leveloffset=+1]
diff --git a/modules/changes-from-oadp-1-4-to-1-5.adoc b/modules/changes-from-oadp-1-4-to-1-5.adoc
@@ -7,7 +7,7 @@
 = Changes from OADP 1.4 to 1.5
 
 [role="_abstract"]
-The Velero server has been updated from version 1.14 to 1.16. 
+The Velero server has been updated from version 1.14 to 1.16.
 
 This changes the following:
 
diff --git a/modules/oadp-1-5-0-release-notes.adoc b/modules/oadp-1-5-0-release-notes.adoc
diff --git a/modules/oadp-1-5-1-release-notes.adoc b/modules/oadp-1-5-1-release-notes.adoc
@@ -8,163 +8,147 @@
 = OADP 1.5.1 release notes
 
 [role="_abstract"]
-The {oadp-first} 1.5.1 release notes lists new features, resolved issues, known issues, and deprecated features.
+The {oadp-first} 1.5.1 release notes list new features, resolved issues, known issues, and deprecated features.
 
 
 [id="new-features-1-5-1_{context}"]
 == New features
 
-*`CloudStorage` API is fully supported*
-
+`CloudStorage` API is fully supported::
 The `CloudStorage` API feature, available as a Technology Preview before this update, is fully supported from {oadp-short} 1.5.1. The `CloudStorage` API automates the creation of a bucket for object storage.
-
++
 link:https://issues.redhat.com/browse/OADP-3307[OADP-3307]
 
-*New `DataProtectionTest` custom resource is available*
-
-The `DataProtectionTest` (DPT) is a custom resource (CR) that provides a framework to validate your {oadp-short} configuration. The DPT CR checks and reports information for the following parameters:
+New `DataProtectionTest` custom resource is available::
+The `DataProtectionTest` (DPT) is a custom resource (CR) that provides a framework to validate your {oadp-short} configuration.
++
+--
+The DPT CR checks and reports information for the following parameters:
 
 * The upload performance of the backups to the object storage.
 * The Container Storage Interface (CSI) snapshot readiness for persistent volume claims.
 * The storage bucket configuration, such as encryption and versioning.
-
+--
++
 Using this information in the DPT CR, you can ensure that your data protection environment is properly configured and performing according to the set configuration.
-
++
 Note that you must configure `STORAGE_ACCOUNT_ID` when using DPT with {oadp-short} on Azure.
-
++
 link:https://issues.redhat.com/browse/OADP-6300[OADP-6300]
 
-*New node agent load affinity configurations are available*
+New node agent load affinity configurations are available::
 
 * *Node agent load affinity:* You can schedule the node agent pods on specific nodes by using the `spec.podConfig.nodeSelector` object of the `DataProtectionApplication` (DPA) custom resource (CR). You can add more restrictions on the node agent pods scheduling by using the `nodeagent.loadAffinity` object in the DPA spec.
 * *Repository maintenance job affinity configurations:* You can use the repository maintenance job affinity configurations in the `DataProtectionApplication` (DPA) custom resource (CR) only if you use Kopia as the backup repository.
 +
 You have the option to configure the load affinity at the global level affecting all repositories, or for each repository. You can also use a combination of global and per-repository configuration.
 * *Velero load affinity:* You can use the `podConfig.nodeSelector` object to assign the Velero pod to specific nodes. You can also configure the `velero.loadAffinity` object for pod-level affinity and anti-affinity.
 
++
 link:https://issues.redhat.com/browse/OADP-5832[OADP-5832]
 
-*Node agent load concurrency is available*
-
+Node agent load concurrency is available::
 With this update, users can control the maximum number of node agent operations that can run simultaneously on each node within their cluster. It also enables better resource management, optimizing backup and restore workflows for improved performance and a more streamlined experience.
 
 
 [id="resolved-issues-1-5-1_{context}"]
 == Resolved issues
 
-*`DataProtectionApplicationSpec` overflowed annotation limit, causing potential misconfiguration in deployments*
-
+`DataProtectionApplicationSpec` overflowed annotation limit, causing potential misconfiguration in deployments::
 Before this update, the `DataProtectionApplicationSpec` used deprecated `PodAnnotations`, which led to an annotation limit overflow. This caused potential misconfigurations in deployments. In this release, we have added `PodConfig` for annotations in pods deployed by the Operator, ensuring consistent annotations and improved manageability for end users. As a result, deployments should now be more reliable and easier to manage.
-
++
 link:https://issues.redhat.com/browse/OADP-6454[OADP-6454]
 
-*Root file system for {oadp-short} controller manager is now read-only*
-
+Root file system for {oadp-short} controller manager is now read-only::
 Before this update, the `manager` container of the `openshift-adp-controller-manager-*` pod was configured to run with a writable root file system. As a consequence, this could allow for tampering with the container's file system or the writing of foreign executables. With this release, the container's security context has been updated to set the root file system to read-only while ensuring necessary functions that require write access, such as the Kopia cache, continue to operate correctly. As a result, the container is hardened against potential threats.
 
-*`nonAdmin.enable: false` in multiple DPAs no longer causes reconcile issues*
-
+`nonAdmin.enable: false` in multiple DPAs no longer causes reconcile issues::
 Before this update, when a user attempted to create a second non-admin `DataProtectionApplication` (DPA) on a cluster where one already existed, the new DPA failed to reconcile. With this release, the restriction on Non-Admin Controller installation to one per cluster has been removed. As a result, users can install multiple Non-Admin Controllers across the cluster without encountering errors.
-
++
 link:https://issues.redhat.com/browse/OADP-6500[OADP-6500]
 
-*{oadp-short} supports self-signed certificates*
-
+{oadp-short} supports self-signed certificates::
 Before this update, using a self-signed certificate for backup images with a storage provider such as Minio resulted in an `x509: certificate signed by unknown authority` error during the backup process. With this release, certificate validation has been updated to support self-signed certificates in {oadp-short}, ensuring successful backups.
-
++
 link:https://issues.redhat.com/browse/OADP-641[OADP-641]
 
-*`velero describe` includes `defaultVolumesToFsBackup`*
-
+`velero describe` includes `defaultVolumesToFsBackup`::
 Before this update, the `velero describe` output command omitted the `defaultVolumesToFsBackup` flag. This affected the visibility of backup configuration details for users. With this release, the `velero describe` output includes the `defaultVolumesToFsBackup` flag information, improving the visibility of backup settings.
-
++
 link:https://issues.redhat.com/browse/OADP-5762[OADP-5762]
 
-*DPT CR no longer fail when `s3Url` is secured*
-
+DPT CR no longer fail when `s3Url` is secured::
 Before this update, `DataProtectionTest` (DPT) failed to run when `s3Url` was secured due to an unverified certificate because the DPT CR lacked the ability to skip or add the caCert in the spec field. As a consequence, data upload failure occurred due to an unverified certificate. With this release, DPT CR has been updated to accept and skip CA cert in spec field, resolving SSL verification errors. As a result, DPT no longer fails when using secured `s3Url`.
-
++
 link:https://issues.redhat.com/browse/OADP-6235[OADP-6235]
 
-*Adding a backupLocation to DPA with an existing backupLocation name is not rejected*
-
+Adding a backupLocation to DPA with an existing backupLocation name is not rejected::
 Before this update, adding a second `backupLocation` with the same name in `DataProtectionApplication` (DPA) caused {oadp-short} to enter an invalid state, leading to Backup and Restore failures due to Velero's inability to read Secret credentials. As a consequence, Backup and Restore operations failed. With this release, the duplicate `backupLocation` names in DPA are no longer allowed, preventing Backup and Restore failures. As a result, duplicate `backupLocation` names are rejected, ensuring seamless data protection.
-
++
 link:https://issues.redhat.com/browse/OADP-6459[OADP-6459]
 
 
 [id="known-issues-1-5-1_{context}"]
 == Known issues
 
-*The restore fails for backups created on OpenStack using the Cinder CSI driver*
-
+The restore fails for backups created on OpenStack using the Cinder CSI driver::
 When you start a restore operation for a backup that was created on an OpenStack platform using the Cinder Container Storage Interface (CSI) driver, the initial backup only succeeds after the source application is manually scaled down. The restore job fails, preventing you from successfully recovering your application's data and state from the backup. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-5552[OADP-5552]
 
-*Datamover pods scheduled on unexpected nodes during backup if the `nodeAgent.loadAffinity` parameter has many elements*
-
+Datamover pods scheduled on unexpected nodes during backup if the `nodeAgent.loadAffinity` parameter has many elements::
 Due to an issue in Velero 1.14 and later, the {oadp-short} node-agent only processes the first `nodeSelector` element within the `loadAffinity` array. As a consequence, if you define multiple `nodeSelector` objects, all objects except the first are ignored, potentially causing datamover pods to be scheduled on unexpected nodes during a backup.
-
++
 To work around this problem, consolidate all required `matchExpressions` from multiple `nodeSelector` objects into the first `nodeSelector` object. As a result, all node affinity rules are correctly applied, ensuring datamover pods are scheduled to the appropriate nodes.
-
++
 link:https://issues.redhat.com/browse/OADP-6469[OADP-6469]
 
-*{oadp-short} Backup fails when using CA certificates with aliased command*
-
+{oadp-short} Backup fails when using CA certificates with aliased command::
 The CA certificate is not stored as a file on the running Velero container. As a consequence, the user experience degraded due to missing `caCert` in Velero container, requiring manual setup and downloads. 
 To work around this problem, manually add cert to the Velero deployment. For instructions, see link:https://access.redhat.com/articles/5456281#using-cacert-with-velero-command-aliased-via-velero-deployment-48[Using cacert with velero command aliased via velero deployment].
-
++
 link:https://issues.redhat.com/browse/OADP-4668[OADP-4668]
 
-*The `nodeSelector` spec is not supported for the Data Mover restore action*
-
+The `nodeSelector` spec is not supported for the Data Mover restore action::
 When a Data Protection Application (DPA) is created with the `nodeSelector` field set in the `nodeAgent` parameter, Data Mover restore partially fails instead of completing the restore operation. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-4743[OADP-4743]
 
-*Image streams backups are partially failing when the DPA is configured with `caCert`*
-
+Image streams backups are partially failing when the DPA is configured with `caCert`::
 An unverified certificate in the S3 connection during backups with `caCert` in `DataProtectionApplication` (DPA) causes the `ocp-django` application's backup to partially fail and result in data loss. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-4817[OADP-4817]
 
-*Kopia does not delete cache on worker node*
-
+Kopia does not delete cache on worker node::
 When the `ephemeral-storage` parameter is configured and running file system restore, the cache is not automatically deleted from the worker node. As a consequence, the `/var` partition overflows during backup restore, causing increased storage usage and potential resource exhaustion. To work around this problem, restart the node agent pod, which clears the cache. As a result, cache is deleted.
-
++
 link:https://issues.redhat.com/browse/OADP-4855[OADP-4855]
 
-*{gcp-short} VSL backups fail with Workload Identity because of invalid project configuration*
-
+{gcp-short} VSL backups fail with Workload Identity because of invalid project configuration::
 When performing a `volumeSnapshotLocation` (VSL) backup on {gcp-short} Workload Identity, the Velero {gcp-short} plugin creates an invalid API request if the {gcp-short} project is also specified in the `snapshotLocations` configuration of `DataProtectionApplication` (DPA). As a consequence, the {gcp-short} API returns a `RESOURCE_PROJECT_INVALID` error, and the backup job finishes with a `PartiallyFailed` status. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-6697[OADP-6697]
 
-*VSL backups fail for `CloudStorage` API on AWS with STS*
-
+VSL backups fail for `CloudStorage` API on AWS with STS::
 The `volumeSnapshotLocation` (VSL) backup fails because of missing the `AZURE_RESOURCE_GROUP` parameter in the credentials file, even if `AZURE_RESOURCE_GROUP` is already mentioned in the `DataProtectionApplication` (DPA) config for VSL. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-6676[OADP-6676]
 
-*Backups of applications with `ImageStreams` fail on Azure with STS*
-
+Backups of applications with `ImageStreams` fail on Azure with STS::
 When backing up applications that include image stream resources on an Azure cluster using STS, the {oadp-short} plugin incorrectly attempts to locate a secret-based credential for the container registry. As a consequence, the required secret is not found in the STS environment, causing the `ImageStream` custom backup action to fail. This results in the overall backup status marked as `PartiallyFailed`. No known workaround exists.
-
++
 link:https://issues.redhat.com/browse/OADP-6675[OADP-6675]
 
-*DPA reconciliation fails for `CloudStorageRef` configuration*
-
+DPA reconciliation fails for `CloudStorageRef` configuration::
 When a user creates a bucket and uses the `backupLocations.bucket.cloudStorageRef` configuration, bucket credentials are not present in the `DataProtectionApplication` (DPA) custom resource (CR). As a result, the DPA reconciliation fails even if bucket credentials are present in the `CloudStorage` CR. To work around this problem, add the same credentials to the `backupLocations` section of the DPA CR.
-
++
 link:https://issues.redhat.com/browse/OADP-6669[OADP-6669]
 
 
 [id="deprecated-features-1-5-1_{context}"]
 == Deprecated features
 
-*The `configuration.restic` specification field has been deprecated*
-
+The `configuration.restic` specification field has been deprecated::
 With {oadp-short} 1.5.0, the `configuration.restic` specification field has been deprecated. Use the `nodeAgent` section with the `uploaderType` field for selecting `kopia` or `restic` as a `uploaderType`. Note that Restic is deprecated in {oadp-short} 1.5.0.
-
++
 link:https://issues.redhat.com/browse/OADP-5158[OADP-5158]
diff --git a/modules/oadp-1-5-2-release-notes.adoc b/modules/oadp-1-5-2-release-notes.adoc
@@ -8,22 +8,24 @@
 = OADP 1.5.2 release notes
 
 [role="_abstract"]
-The {oadp-first} 1.5.2 release notes lists resolved issues.
+The {oadp-first} 1.5.2 release notes list resolved issues.
 
 [id="resolved-issues-1-5-2_{context}"]
 == Resolved issues
 
-*Self-signed certificate for internal image backup should not break other BSLs*
-
-Before this update, {oadp-short} would only process the first custom CA certificate found among all backup storage locations (BSLs) and apply it globally. This behavior prevented multiple BSLs with different CA certificates from working correctly. 
+Self-signed certificate for internal image backup should not break other BSLs::
+Before this update, {oadp-short} would only process the first custom CA certificate found among all backup storage locations (BSLs) and apply it globally. This behavior prevented multiple BSLs with different CA certificates from working correctly.
 Additionally, system-trusted certificates were not included, causing failures when connecting to standard services.
++
+--
 With this update, {oadp-short} now:
 
 * Concatenates all unique CA certificates from {aws-short} BSLs into a single bundle.
 * Includes system-trusted certificates automatically.
 * Enables multiple BSLs with different custom CA certificates to operate simultaneously.
 * Only processes CA certificates when image backup is enabled (default behavior).
-
+--
++
 This enhancement improves compatibility for environments using multiple storage providers with different certificate requirements, particularly when backing up internal images to {aws-short} S3-compatible storage with self-signed certificates.
-
++
 link:https://issues.redhat.com/browse/OADP-6765[OADP-6765]
diff --git a/modules/oadp-verifying-upgrade-1-5-0.adoc b/modules/oadp-verifying-upgrade-1-5-0.adoc
@@ -19,7 +19,7 @@ $ oc get dpa dpa-sample -n openshift-adp
 ----
 +
 .Example output
-+
+[source,terminal]
 ----
 NAME            RECONCILED   AGE
 dpa-sample      True         2m51s
@@ -38,7 +38,7 @@ $ oc get all -n openshift-adp
 ----
 +
 .Example output
-+
+[source,terminal]
 ----
 NAME                                                    READY   STATUS    RESTARTS   AGE
 pod/node-agent-9pjz9                                    1/1     Running   0          3d17h
@@ -78,9 +78,9 @@ In {oadp-short} 1.4.0 and {oadp-short} 1.3.0 version, the `node-agent` pods are
 ----
 $ oc get backupstoragelocations.velero.io -n openshift-adp
 ----
-.Example output
-[source,yaml]
 +
+.Example output
+[source,terminal]
 ----
 NAME           PHASE       LAST VALIDATED   AGE     DEFAULT
 dpa-sample-1   Available   1s               3d16h   true
