Upgrade VMware Telco Cloud Service Assurance CNF

In this section, you can find information on how to upgrade the tcsa CNF.

Procedure

Launch VMware Telco Cloud Automation and navigate to Inventory > Network Function.
To upgrade, select the base version of the tcsa CNF and click the vertical ellipsis (⋮) and click Upgrade.
In the Upgrade Revision section, select the version of the tcsa CNF that you want to upgrade to and click Next.
In the Inventory Detail section, select the Namespace as tcsa-system and select the Repo URL as <oci://<registryRootUrl>>, and click Next.

Note: Use the same registryRootUrl as specified during the push artifacts to registry step.
In the Inputs section, update the following parameters:
Note: The following parameters can be updated by referrening the output of the populateTcsaValuesYaml.sh script.
1. Set registryRootUrl to the regsitry URL used while pushing the artifacts.
2. Set dashboardAccess.ip to the same IP address as specified during the earlier VMware Telco Cloud Service Assurance deployment.
3. Set dashboardAccess.type to the same value as specified during the earlier VMware Telco Cloud Service Assurance deployment.
4. Set footprint production.
  Note: If the base version is 25K or higher, then update the footprint as production.
5. Set edgeServicesAccessIp to the same value as specified during the earlier VMware Telco Cloud Service Assurance deployment.
6. All the Backup and Restore values must be same as specified during the earlier VMware Telco Cloud Service Assurance deployment.
  - If AWS S3 is used for backup, then update the following parameters:
```
backupAndRestore.minioDatastoreType
backupAndRestore.bucketName
backupAndRestore.s3AccessKey
backupAndRestore.s3SecretKey
```
  - If NFS is used for backup, then update the following parameters:
```
backupAndRestore.minioDatastoreType
backupAndRestore.nfsProvisionerEnabled
backupAndRestore.bucketName
backupAndRestore.nfsServer
backupAndRestore.nfsPath
```
7. The default value for the healthMonitoring.s3BucketName field is prometheus-metrics. You must change this default value if you are creating multiple VMware Telco Cloud Service Assurance instances while you are using NFS or AWS S3 bucket.
8. The following configuration parameters must be updated by referring the values-user-overrides.yaml file.
  1. flexibleConfig.managedDevices
  2. flexibleConfig.incomingEvents
  3. flexibleConfig.incomingMetrics
  4. flexibleConfig.percentMetricsForAnomaly
  5. flexibleConfig.percentMetricsForAlarms
  6. flexibleConfig.retentionInterval
9. (Optional) The following parameters belong to a flexible scaling parameter for retention interval and are optional.
```
flexibleConfig.retentionIntervalForLongTermData.metricHourlyRollupData
```
  For example, If the default value for the Flexible Scaling Parameter for metricHourlyRollupData retention is empty. If you do not update this value then by default it is updated to 4w (weeks). If you want to update it then you can update it to 1w or 2w or 3w and so on.
```
flexibleConfig.retentionIntervalForLongTermData.metricDailyRollupData
```
  For example, If the default value for the Flexible Scaling Parameter for metricDailyRollupData retention is empty. If you do not update this value then by default it is updated to 1m (month). If you want to update it then you can update it to 1m or 2m or 3m and so on.
```
flexibleConfig.retentionIntervalForLongTermData.metricWeeklyRollupData
```
  For example, If the default value for the Flexible Scaling Parameter for metricWeeklyRollupData retention is empty. If you do not update this value then by default it is updated to 1y (year). If you want to update it then you can update it to 1y or 2y or 3y and so on.
```
flexibleConfig.retentionIntervalForLongTermData.eventHistory
Flexible Scaling Parameter for Event History data retention (in Days | Example:31d)
```
  For example, If the default value for the Flexible Scaling Parameter for eventHistory retention is empty. If you do not update this value then by default it is updated to 31d (days). If you want to update it then you can update it to 1d or 2d or 3d and so on.
10. (Optional) The following parameters belong to a flexible scaling parameter for Alerts for OI Server Per Sec and are optional.
```
flexibleConfig.alertsForOIServerPerSec
```
  For example, If the default value for the Flexible Scaling Parameter for alertsForOIServerPerSec retention is empty. If you do not update this value then by default it is updated to 0. If you want to update it then you can update it to any values between 0 to 200.
11. (Optional) The following parameters belong to a flexible scaling parameter for number of Traps or Syslog Per Sec and are optional.
```
flexibleConfig.noOfTrapsOrSyslogPerSec
```
  For example, If the default value for the Flexible Scaling Parameter for noOfTrapsOrSyslogPerSec retention is empty. If you do not update this value then by default it is updated to 0. If you want to update it then you can update it to any values between 0 to 200.
  Note: The total values of alertsForOIServerPerSec and noOfTrapsOrSyslogPerSec must be less than or equal to 200.
12. While upgrading from VMware Telco Cloud Service Assurance 2.1 or 2.2 to 2.3 or 2.3.1 to 2.4, set skipKafkaEdgeRawTopicCreation to true. While upgrading from 2.3.0 or 2.3.1 to 2.4.0, set skipKafkaEdgeRawTopicCreation to false.
13. The default value for grafanaScheduledExportEnabled is false.
14. Click Next.
Under Network Function Properties, click Next.
In the Review section, click Upgrade.
After the upgrade is complete, you can see the state as completed as shown in the following screenshot.
Note: Once the upgrade is shown as completed in VMware Telco Cloud Automation UI, in the background the application continues to deploy.
You can manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from deployment VM.
```
root [ ~/upgrade/tcx-deployer/scripts ]# kubectl get tcxproduct -A
 OR
root [ ~/upgrade/tcx-deployer/scripts ]# kubectl get apps -A
```
For all the apps, the reconciliation status must be successful.
```
kubectl get tcxproduct -A
NAMESPACE     NAME                                            STATUS            READY   MESSAGE                               AGE
tcsa-system   tcsa-240-48742-p2fmq                            updateCompleted   True    All App CRs reconciled successfully   39m
tps-system    tcx-platfor-9037e-pdyey-tcx-platform-services   updateCompleted   True    All App CRs reconciled successfully   49m
```
Note: After successful deployment, you can launch the VMware Telco Cloud Service Assurance UI. For more information, see Accessing UI topic. Ensure that the About page in VMware Telco Cloud Service Assurance UI reflects the upgraded version of VMware Telco Cloud Service Assurance.
If all the apps are not reconciled, the deployment fails. For more information, see VMware Telco Cloud Automation Upgrade topic in the VMware Telco Cloud Service Assurance Troubleshooting Guide.
After the upgrade is successful, you must execute the postUpgrade.sh script for cleaning the stale entries from the deployer host.
```
$TCSA_WORK_SPACE/tcx-deployer/scripts/postUpgrade.sh <your-kubeconfig-location>
```
After the VMware Telco Cloud Service Assurance upgrade is successful, follow the steps mentioned in the Post Upgrade topic.

What to do next

After the VMware Telco Cloud Service Assurance upgrade is successful, follow the steps mentioned in the Post Upgrade topic.

After perfoming the steps in the Post Upgrade, you must upgrade all the remote data collector managers. For more information, see Upgrading Remote Collector Manager.

Note:

If you do not have a remote data collector manager then you can skip this step.
If the user wants to enable the Grafana Schedule and Export Reports post the deployment, then follow the procedure mentioned in the Optional feature : Enabling Grafana Schedule and Export Reports Feature section.

After perfoming the steps in the Upgrading Remote Collector Manager, you must upgrade the domain managers as mentioned in the Upgrade Domain Manager topic.

Note: If there are any SSL Handshake errors and the discovery fails in the Domain Managers while discovering VMware Aria Operations, VMware Telco Cloud Automation, Cisco ACI, VCD, and VIMS after upgrading the Domain Manager and VMware Telco Cloud Service Assurance Core then to regenerate the Kafka Edge Certificate follow the procedure given in the SSL Handshake Error Post TCSA and Domain Manager Upgrade topic given in the VMware Telco Cloud Service Assurance Troubleshooting Guide.