Merge pull request #79766 from ogradyp/TELCODOCS-1929

TELCODOCS-1929: Docs & RN: Deprecation of TALM B&R

Author: mburke5678

edge_computing/cnf-talm-for-cluster-upgrades.adoc

@@ -39,12 +39,6 @@ include::modules/cnf-topology-aware-lifecycle-manager-about-subscription-crs.ado
 
 include::modules/cnf-topology-aware-lifecycle-manager-apply-policies.adoc[leveloffset=+2]
 
-include::modules/cnf-topology-aware-lifecycle-manager-backup-concept.adoc[leveloffset=+1]
-
-include::modules/cnf-topology-aware-lifecycle-manager-backup-feature.adoc[leveloffset=+2]
-
-include::modules/cnf-topology-aware-lifecycle-manager-backup-recovery.adoc[leveloffset=+2]
-
 include::modules/cnf-topology-aware-lifecycle-manager-precache-concept.adoc[leveloffset=+1]
 
 include::modules/cnf-topology-aware-lifecycle-manager-precache-image-filter.adoc[leveloffset=+2]

modules/cnf-about-topology-aware-lifecycle-manager-config.adoc

@@ -16,9 +16,6 @@ The {cgu-operator-first} manages the deployment of {rh-rhacm-first} policies for
 * The order of policies remediated to the cluster
 * The assignment of a canary cluster
 
-For {sno}, the {cgu-operator-first} offers the following features:
-
-* Create a backup of a deployment before an upgrade
-* Pre-caching images for clusters with limited bandwidth
+For {sno}, the {cgu-operator-first} offers pre-caching images for clusters with limited bandwidth.
 
 {cgu-operator} supports the orchestration of the {product-title} y-stream and z-stream updates, and day-two operations on y-streams and z-streams.

modules/cnf-topology-aware-lifecycle-manager-about-cgu-crs.adoc

@@ -87,7 +87,6 @@ Spec:
     beforeEnable: <2>
       addClusterLabels:
         upgrade-running: ""
-  backup: false
   clusters: <3>
     - spoke1
   enable: false <4>
@@ -200,22 +199,6 @@ Pre-caching is still in progress for one or more clusters or has failed for all
 
 For more information see the "Using the container image pre-cache feature" section.
 
-[id="creating_backup_{context}"]
-== Creating a backup
-
-For {sno}, {cgu-operator} can create a backup of a deployment before an update. If the update fails, you can recover the previous version and restore a cluster to a working state without requiring a reprovision of applications. To use the backup feature you first create a `ClusterGroupUpgrade` CR with the `backup` field set to `true`. To ensure that the contents of the backup are up to date, the backup is not taken until you set the `enable` field in the `ClusterGroupUpgrade` CR to `true`.
-
-{cgu-operator} uses the `BackupSucceeded` condition to report the status and reasons as follows:
-
-* `true`
-+
-Backup is completed for all clusters or the backup run has completed but failed for one or more clusters. If backup fails for any cluster, the update fails for that cluster but proceeds for all other clusters.
-* `false`
-+
-Backup is still in progress for one or more clusters or has failed for all clusters.
-
-For more information, see the "Creating a backup of cluster resources before upgrade" section.
-
 [id="updating_clusters_{context}"]
 == Updating clusters
 {cgu-operator} enforces the policies following the remediation plan.
@@ -231,10 +214,9 @@ Enforcing the policies for subsequent batches starts immediately after all the c
 The update is not in progress. Possible reasons for this are:
 +
 ** All clusters are compliant with all the managed policies.
-** The update has timed out as policy remediation took too long.
+** The update timed out as policy remediation took too long.
 ** Blocking CRs are missing from the system or have not yet completed.
 ** The `ClusterGroupUpgrade` CR is not enabled.
-** Backup is still in progress.
 
 [NOTE]
 ====
@@ -261,7 +243,6 @@ Spec:
     afterCompletion:
       deleteObjects: true
     beforeEnable: {}
-  backup: false
   clusters:
     - spoke1
   enable: true
@@ -420,7 +401,6 @@ spec:
     afterCompletion:
       deleteObjects: true
     beforeEnable: {}
-  backup: false
   clusters:
     - spoke1
     - spoke2