Merge pull request #290000 from msftadam/patch-43

Update best-practices-onboard-deploy.md

Author: prmerger-automator[bot]

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

@@ -274,56 +274,40 @@ The component name is defined in the NFDV:
 
 ## Cleanup considerations
 
-Delete operator resources in the following order to make sure no orphaned resources are left behind:
-
+### Operator Resources
+As the first step towards cleaning up a deployed environment, start by deleting operator resources in the following order:
 - SNS
 - Site
 - CGV
 
-> [!IMPORTANT]
-> Make sure SNS is deleted before you delete the NFDV.
+Only once these operator resources are succesfully deleted, should a user proceed to delete other environment resources, such as the NAKS cluster.
 
-Delete publisher resources in the following order to make sure no orphaned resources are left behind:
+> [!IMPORTANT]
+> Deleting resources out of order can result in orphaned resources left behind.
 
-- CGS
+### Publisher Resources
+As the first step towards cleaning up an onboarded environment, start by deleting publisher resources in the following order:
 - NSDV
 - NSDG
+
+> [!IMPORTANT]
+> Make sure SNS is deleted before you delete the NFDV.
+
 - NFDV
 - NFDG
 - Artifact Manifest
 - Artifact Store
 - Publisher
 
-## Considerations if your NF runs cert-manager
-
 > [!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.
-
-### Other Configuration Changes to Consider
-
-In addition to disabling the NfApp associated with the old user cert-manager, we have found other changes may be needed;
-1.	If one NfApp contains both cert-manager and the CA installation, these must broken into two NfApps, so that the partner can disable cert-manager but enable CA installation.
-2.	If any other NfApps have DependsOn references to the old user cert-manager NfApp, these will need to be removed. 
-3.	If any other NfApps reference the old user cert-manager namespace value, this will need to be changed to the new azurehybridnetwork namespace value.  
-
-### Cert-Manager Version Compatibility & Management
-
-For the cert-manager operator, our current deployed version is 1.14.5.  Users should test for compatibility with this version.  Future cert-manager operator upgrades will be supported via the NFO extension upgrade process. 
-
-For the CRD resources, our current deployed version is 1.14.5.  Users should test for compatibility with this version.  Since management of a common cluster CRD is something typically handled by a cluster administrator, we are working to enable CRD resource upgrades via standard Nexus Add-on process. 
+> Deleting resources out of order can result in orphaned resources left behind.
 
 ## NfApp Sequential Ordering Behavior
 
 ### Overview
-
 By default, containerized network function applications (NfApps) are installed or updated based on the sequential order in which they appear in the network function design version (NFDV). For delete, the NfApps are deleted in the reverse order sepcified. Where a publisher needs to define specific ordering of NfApps, different from the default, a dependsOnProfile is used to define a unique sequence for install, update and delete operations.
 
 ### How to use dependsOnProfile
-
 A publisher can use the dependsOnProfile in the NFDV to control the sequence of helm executions for NfApps. Given the following example, on install operation the NfApps will be deployed in the following order: dummyApplication1, dummyApplication2, then dummyApplication. On update operation, the NfApps will be updated in the following order: dummyApplication2, dummyApplication1, then dummyApplication. On delete operation, the NfApps will be deleted in the following order: dummyApplication2, dummyApplication1, then dummyApplication.
 
 ```json
@@ -373,7 +357,6 @@ A publisher can use the dependsOnProfile in the NFDV to control the sequence of
 ```
 
 ### Common Errors
-
 As of today, if dependsOnProfile provided in the NFDV is invalid, the NF operation will fail with a validation error. The validation error message is shown in the operation status resource and looks similar to the following example.
 
 ```json

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

@@ -75,7 +75,7 @@ Through Microsoft’s Secure Future Initiative (SFI), this release delivers the
 
 * NFO	- Signing of helm package used by network function extension.
 * NFO	- Signing of core image used by network function extension.
-* NFO	- Use of Cert-manager for service certificate management and rotation. This change can result in failed SNS deployments if not properly reconciled. For guidance on the impact of this change, see our [best practice recommendations](best-practices-onboard-deploy.md#considerations-if-your-nf-runs-cert-manager).
+* NFO	- Use of Cert-manager for service certificate management and rotation. This change can result in failed SNS deployments if not properly reconciled.
 * NFO	- Automated refresh of AOSM certificates during extension installation.
 * NFO	- A dedicated service account for the preupgrade job to safeguard against modifications to the existing network function extension service account.
 * RP - The service principles (SPs) used for deploying site & Network Function (NF) now require “Microsoft.ExtendedLocation/customLocations/read” permission. The SPs that deploy day N scenario now require "Microsoft.Kubernetes/connectedClusters/listClusterUserCredentials/action" permission. This change can result in failed SNS deployments if not properly reconciled