Upgrade
VMware Telco Cloud Service Assurance
CNF

In this section, you can find information on how to upgrade the
tcsa
CNF.
  1. Launch VMware Telco Cloud Automation and navigate to
    Inventory
    Network Function
    .
  2. To upgrade, select the base version of the
    tcsa
    CNF and click the vertical ellipsis (⋮) and click
    Upgrade
    .
  3. In the
    Upgrade Revision
    section, select the version of the
    tcsa
    CNF that you want to upgrade to and click
    Next
    .
    TCSA Upgrade Revision
  4. In the
    Inventory Detail
    section, select the
    Namespace
    as
    tcsa-system
    and select the
    Repo URL
    as
    <oci://<registryRootUrl>>
    , and click
    Next
    .
    Use the same
    registryRootUrl
    as specified during the
    push artifacts to registry
    step.
    TCSA Inventory Detail
  5. In the
    Inputs
    section, update the following parameters:
    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.
      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 VMware vSAN or NFS file service 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.
      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. Click
      Next
      .
  6. Under
    Network Function Properties
    , click
    Next
    .
  7. In the
    Review
    section, click
    Upgrade
    .
  8. After the upgrade is complete, you can see the state as completed as shown in the following screenshot.
    TCSA Upgrade State
    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
    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
    .
  9. 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>
  10. After the
    VMware Telco Cloud Service Assurance
    upgrade is successful, follow the steps mentioned in the Post Upgrade topic.
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.
If you do not have a remote data collector manager then you can skip this step.
After perfoming the steps in the Upgrading Remote Collector Manager, you must upgrade the domain managers as mentioned in the Upgrade Domain Manager topic.
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
.