You can rollback the VMware Telco Cloud Service Assurance patch to the base version or the previous version of the patch using the helm rollback command.

Prerequisites

To rollback the patch, you must install the Helm package on the Deployment Host.

Rollback of Patch on VMware Tanzu Kubernetes Grid and AKS

For example, in CLI based patch rollback, Revision number 1 refers to VMware Telco Cloud Service Assurance 2.2 GA and Revision number 2 refers to VMware Telco Cloud Service Assurance 2.2 Patch x. 
root [ ~/.kube ]# helm list
NAME    NAMESPACE       REVISION        UPDATED                                   STATUS     CHART          APP VERSION
tcsa    default         2               2023-07-17 18:59:03.569762668 +0000 UTC   deployed   tcsa-2.2.0-1   0.0.0
root [ ~/.kube ]# helm history tcsa
REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Mon Jul 17 16:50:20 2023        superseded      tcsa-2.2.0      0.0.0           Install complete
2               Mon Jul 17 18:59:03 2023        deployed        tcsa-2.2.0-1    0.0.0           Upgrade complete
  • If you want to rollback to the base version, you must select Revision number 1. For example:
    root [ ~/tcx-deployer/scripts ]# helm rollback tcsa 1
  • Verify the successful execution of the helm rollback command.
  • Verify that all apps are successfully reconciled by running the kubectl get apps command.

Rollback of Patch through VMware Telco Cloud Automation

To rollback, perform the following steps:
  1. To rollback the changes, navigate to Inventory > Network Function, click the three dots against the CNF to rollback as part of the patch and select Upgrade. Select the older CSAR file (for example, tcsa.csar) that you onboarded and update the parameters same as the initial VMware Telco Cloud Service Assurance deployment.
  2. Select Upgrade.PatchRollbackUpgrade
  3. In the Upgrade Revision section, select the old CSAR file that you onboarded. For example, tcsa.csar. Click Next.PatchRollbackUpgradeRevision
  4. In the Inventory Detail section, ensure that the Namespace is set to default and select the default library chart repository, that is, the https://<harbor-registry-fqdn>/chartrepo/library endpoint of the associated registry, and click Next.PatchRollbackInventoryDetail
  5. In the Inputs section, update the following parameters:
    • Set registryRootUrl to the registry URL used while pushing the artifacts.
    • Set dashboardStaticAccessIp to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
    • Set footprint same as the base version. For example, demo, 25k, 50k, 75k, 100k, and so on.
    • (Optional) Set edgeServicesAccessIp to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
    • Set statusChecker.enabled to disabled state if it is enabled. The default value is disabled.
      Note: The statusChecker.enabled parameter is disabled in VMware Telco Cloud Service Assurance because VMware Telco Cloud Automation does not support CNF timeouts.
    • Set elasticsearch.retentionInterval to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
    • Set appSpecs.elasticsearch.additionalValuesFile to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
    • All the Backup and Restore values must be same as specified during the base VMware Telco Cloud Service Assurance deployment.
    • Click Next.PatchRollbackInputs
  6. The Network Function Properties page appears. Click Next.PatchRollbackNetworkFunctions
  7. In the Review section, click Upgrade.PatchRollbackReview

    After the upgrade is successful, you can see the CNF rolled back to the original state.

Manually check the VMware Telco Cloud Service Assurance patch rollback status by running the following command from deployment VM: 
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct 
 OR
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
For all the apps, the reconcilation status must be successful.
Note: After the patch is deployed, you can view the VMware Telco Cloud Service Assurance version in the About page of VMware Telco Cloud Service Assurance UI.

Rollback of Patch on VM Based VMware Telco Cloud Service Assurance Deployment with Native Kubernetes

For example, in CLI based patch rollback, Revision number 1 refers to VMware Telco Cloud Service Assurance 2.2 GA and Revision number 2 refers to VMware Telco Cloud Service Assurance 2.2 Patch x. 
root [ ~/.kube ]# helm list
NAME    NAMESPACE       REVISION        UPDATED                                   STATUS     CHART          APP VERSION
tcsa    default         2               2023-07-17 18:59:03.569762668 +0000 UTC   deployed   tcsa-2.2.0-1   0.0.0
root [ ~/.kube ]# helm history tcsa
REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Mon Jul 17 16:50:20 2023        superseded      tcsa-2.2.0      0.0.0           Install complete
2               Mon Jul 17 18:59:03 2023        deployed        tcsa-2.2.0-1    0.0.0           Upgrade complete
  • If you want to rollback to the base version, you must select Revision number 1. For example:
    root [ ~/tcx-deployer/scripts ]# helm rollback tcsa 1
  • Verify the successful execution of the helm rollback command.
  • Verify that all apps are successfully reconciled by running the kubectl get apps command.
Note: After the patch is rolled back, you can view the VMware Telco Cloud Service Assurance version in the About page of VMware Telco Cloud Service Assurance UI.