Merge pull request #285920 from msftadam/patch-13

Update safe-upgrades-nf-level-rollback.md

Author: prmerger-automator[bot]

articles/operator-service-manager/best-practices-onboard-deploy.md

@@ -293,7 +293,10 @@ Delete publisher resources in the following order to make sure no orphaned resou
 
 ## Considerations if your NF runs cert-manager
 
-With release 1.0.2728-50 and later , AOSM now uses cert-manager to store and rotate certificates. As part of this change, AOSM deploys a cert-manager operator, and associate CRDs, in the azurehybridnetwork namespace. Since having multiple cert-manager operators, even deployed in separate namespaces, will watch across all namespaces, only one cert-manager can be effectively run on the cluster.
+> [!IMPORTANT]
+> This guidance applies only to certain releases. Check your version for proper behavior.
+
+From release 1.0.2728-50 to release Version 2.0.2777-132, AOSM uses cert-manager to store and rotate certificates. As part of this change, AOSM deploys a cert-manager operator, and associate CRDs, in the azurehybridnetwork namespace. Since having multiple cert-manager operators, even deployed in separate namespaces, will watch across all namespaces, only one cert-manager can be effectively run on the cluster.
 
 Any user trying to install cert-manager on the cluster, as part of a workload deployment, will get a deployment failure with an error that the CRD “exists and cannot be imported into the current release.”  To avoid this error, the recommendation is to skip installing cert-manager, instead take dependency on cert-manager operator and CRD already installed by AOSM.
 

articles/operator-service-manager/release-notes.md

@@ -1,6 +1,6 @@
 ---
-title: Azure Operator Service Manager Release Notes
-description: Tracking of major and minor releases of Azure Operator Service Manager.
+title: Release notes for Azure Operator Service Manager
+description: Official documentation and tracking for major and minor releases.
 author: msftadam
 ms.author: adamdor
 ms.date: 08/14/2024
@@ -149,7 +149,7 @@ The following bug fixes, or other defect resolutions, are delivered with this re
 
 None
 
-## Release Version 2.0.2788-135
+## Release 2.0.2788-135
 
 Document Revision 1.1
 
@@ -160,7 +160,7 @@ Azure Operator Service Manager is a cloud orchestration service that enables aut
 * Release Version: Version 2.0.2788-135
 * Release Date: August 21, 2024
 * Is NFO update required: YES, Update only
-*  Dependency Versions: Go/1.22.4  Helm/3.15.2
+* Dependency Versions: Go/1.22.4  Helm/3.15.2
 
 ### Release Installation
 This release can be installed with as an update on top of release 2.0.2783-134.  

articles/operator-service-manager/safe-upgrade-practices.md

@@ -1,9 +1,9 @@
 ---
-title: Safe Upgrade Practices for CNFs
-description: Safely execute complex upgrades of workloads with Azure Operator Service Manager.
+title: Get started with Azure Operator Service Manager Safe Upgrade Practices 
+description: Safely execute complex upgrades of CNF workloads on Azure Operator Nexus
 author: msftadam
 ms.author: adamdor
-ms.date: 08/16/2024
+ms.date: 08/30/2024
 ms.topic: upgrade-and-migration-article
 ms.service: azure-operator-service-manager
 ---

articles/operator-service-manager/safe-upgrades-nf-level-rollback.md

@@ -1,29 +1,31 @@
 ---
-title: Rollback on upgrade failure using Azure Operator Service Manager
-description: Revert all prior completed operations during safe upgrade failure.
+title: Control upgrade failure behavior with Azure Operator Service Manager
+description: Learn about recovery behaviors including pause on failure and rollback on failure.
 author: msftadam
 ms.author: adamdor
-ms.date: 08/28/2024
+ms.date: 08/30/2024
 ms.topic: upgrade-and-migration-article
 ms.service: azure-operator-service-manager
 ---
 
-# Rollback on upgrade failure
-This guide describes the Azure Operator Service Manager (AOSM) optional rollback on failure feature for container network functions (CNFs). This feature, as part of the AOSM safe upgrade practices initiative, reduces the service impact of unexpected upgrade failures for network functions (NFs) where comprehensive forward and backward version network function application (NfApp) compatibility is not available.
+# Control upgrade failure behavior
+
+## Overview
+This guide describes the Azure Operator Service Manager (AOSM) upgrade failure behavior features for container network functions (CNFs). These features, as part of the AOSM safe upgrade practices initiative, offer a choice between faster retries, with pause on failure, versus return to starting point, with rollback on failure.
 
 ## Pause on failure
-In the case of an unexpected failure during an upgrade, historically AOSM supports the pause on failure approach. This method remains the default and implements the following workflow logic;
-* The NfApps are created or upgraded following either updateDependsOn ordering, if provided, or in the sequential order they appear.
-* NfApps with parameter "applicationEnabled" disabled are skipped.
-* NFApps present before upgrade, but not referenced by the new network function definition version (NFDV) are deleted.
-* The execution is paused if any of the NfApp upgrades fail.
+Any upgrade using AOSM starts with a site network service (SNS) reput opreation. The reput operation processes the network function applications (NfApps) found in the network function design version (NFDV). The reput operation implements the following default logic:
+* NfApps are processed following either updateDependsOn ordering, or in the sequential order they appear.
+* NfApps with parameter "applicationEnabled" set to disable are skipped.
+* NFApps present, but not referenced by the new NFDV are deleted.
+* The execution sequence is paused if any of the NfApp upgrades fail and a rollback is considered.
 * The failure leaves the NF resource in a failed state.
 
-With pause on failure, AOSM rolls back the failed NfApp, via the testOptions, installOptions, or upgradeOptions parameters. This method allows the end user to troubleshoot the failed NfApp and then restart the upgrade from that point forward. As the default behavior, this method is the most efficient upgrade method, but may cause network function (NF) inconsistencies while in a mixed version state. 
+With pause on failure, AOSM rolls back only the failed NfApp, via the testOptions, installOptions, or upgradeOptions parameters. No action is taken on any NfApps which proceed the failed NfApp.  This method allows the end user to troubleshoot the failed NfApp and then restart the upgrade from that point forward. As the default behavior, this method is the most efficient method, but may cause network function (NF) inconsistencies while in a mixed version state. 
 
 ## Rollback on failure
-To address risk of mismatched NfApp versions, AOSM now supports NF level rollback on failure. With this option enabled, if an NfApp upgrade fails, both the failed NfApp, and all prior completed NfApps, are rolled back to initial version state. This method minimizes, or eliminates, the amount of time the NF is exposed to NfApp version mismatches. The optional rollback on failure feature works as follows:
-* A user initiates an upgrade and enables the rollback on failure feature.
+To address risk of mismatched NfApp versions, AOSM now supports NF level rollback on failure. With this option enabled, if an NfApp operation fails, both the failed NfApp, and all prior completed NfApps, can be rolled back to initial version state. This method minimizes, or eliminates, the amount of time the NF is exposed to NfApp version mismatches. The optional rollback on failure feature works as follows:
+* A user initiates an sSNS reput operation and enables rollback on failure.
 * A snapshot of the current NfApp versions is captured and stored.
 * The snapshot is used to determine the individual NfApp actions taken to reverse actions that completed successfully.
   - "helm install" action on deleted components,
@@ -52,7 +54,6 @@ AOSM returns the following operational status and messages, given the respective
     - Provisioning State: Failed
     - Message: Application(<ComponentName>) : <Failure reason>; Rollback Failed (<RollbackComponentName>) : <Rollback Failure reason>
 ```
-
 ## How to configure rollback on failure
 The most flexible method to control failure behavior is to extend a new configuration group schema (CGS) parameter, rollbackEnabled, to allow for configuration group value (CGV) control via roleOverrideValues in the NF payload. First, define the CGS parameter: 
 ```