To configure VMware Telco Cloud Service Assurance with private network, update the parameters in the values.yaml file available in $TCSA_WORK_SPACE/tcx-deployer/product-helm-charts/tcsa.

Step 1 Deployment

root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/product-helm-charts/tcsa
root [ ~/base/tcx-deployer/product-helm-charts/tcsa ]# vi values.yaml

Update the required parameters in the values.yaml file.

  • Use the same registryRootUrl as the previously deployed VMware Telco Cloud Service Assurance version.
    # Default values for tcsa.
# This is a YAML-formatted file.
# Customize your TCSA deployment here by configuring the parameters that are exposed.
# Uncomment the relevant lines and configure them according to your environment.


# (string) registryRootUrl is the FQDN of the registry that has the artifacts.
registryRootUrl: <Registry-root-URL-previously-deployed>
  • Use the same footprint size as the previously deployed VMware Telco Cloud Service Assurance version.
    # (string) footprint is the number of devices monitored by TCSA.
# allowed values for footprint "demo", "25k", "50k", "75k", "100k", "125k", "150k", "175k", "200k"
footprint: <Footprint-previously-deployed>
  • Set privateNetwork to true.
    # ----IaaS configuration----
# (bool) privateNetwork indicates if TCSA is being deployed on a private EKS or AKS network
privateNetwork: true
  • Set cloud provider as aws for deploying VMware Telco Cloud Service Assurance on private network.
    # (string) cloud indicates the cloud/K8s provider. Valid values are "tkg", "aws", "azure" and "on-prem"
cloud: aws
  • Use the same retention interval as the previously deployed VMware Telco Cloud Service Assurance version.
    elasticsearch:
  retentionInterval: <retention-interval-previously-deployed>
  • All the Backup and Restore values must be same as specified during the previous VMware Telco Cloud Service Assurance deployment.
  • Update the same values as the previously deployed VMware Telco Cloud Service Assurance version for subnet-ID values in the values.yaml file.
    eks:
# (list) Set loadBalancerSubnets to:
#    - All the private subnets used for the EKS cluster (for private networks)
  loadBalancerSubnets:
loadBalancerSubnets:
  - <subnet-ID-previously-deployed>
  - <subnet-ID-previously-deployed>
edge:
# (list) Set loadBalancerSubnets to:
#    - All the private subnets used for the EKS cluster (for private networks)
  loadBalancerSubnets:
    - <subnet-ID-previously-deployed>
    - <subnet-ID-previously-deployed>
  • Run the following Docker login command to get the ECR password.
    aws ecr get-login-password --region <aws-region> | docker login --username <your-aws-username> --password-stdin <your-profile-ID>.dkr.ecr.<aws-region>.amazonaws.com
  • Trigger deployment using tcxctl CLI.
    root [ ~ ]# cd /TCSA_WORK_SPACE/tcx-deployer/clis
root [ ~/base/tcx-deployer/clis ]# ./tcxctl deploy all --bundle-path <TCSA-bundle-path> --kubeconfig <your-kubeconfig-location> --registry <your-profile-ID>.dkr.ecr.<aws-region>.amazonaws.com/<project-name> --timeout <time-in-mins>
    Note: The --registry value must be configured with the same value which is used during the previous version of VMware Telco Cloud Service Assurance deployment.
    After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM. 
    root [ ~/base/tcx-deployer/scripts ]# kubectl get tcxproduct 
 OR
root [ ~/base/tcx-deployer/scripts ]# kubectl get apps
    To access the VMware Telco Cloud Service Assurance user interface through DNS hostname, perform the following steps:
    • Run the following command to get the EXTERNAL-IP of dashboardDynamicAccessIp parameter.
          root [ ~/base/tcx-deployer/scripts ]# kubectl get svc istio-ingressgateway -n istio-system
    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP                                                                       PORT(S)                                     E
    istio-ingressgateway   LoadBalancer   172.20.80.229    k8s-istiosys-istioing-7f6b68cc6f-d4c37fd861fdc68d.elb.us-west-2.amazonaws.com   15021:30022/TCP,80:30081/TCP,443:30003/TCP
    • Get the highlighted ExternalIP from the above output and assign it to the dashboardDynamicAccessIpparameter in the values.yaml file.
      dashboardDynamicAccessIp: <ExternalIP>

Step 2 Deployment

  • Redeploy the VMware Telco Cloud Service Assurance by updating the dashboardDynamicAccessIp as part of step 1 deployment.
  • Trigger deployment by running the following installation scripts using tcxctl.
    root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/clis
root [ ~/base/tcx-deployer/clis ]# ./tcxctl deploy product --name tcsa --kubeconfig <your-kubeconfig-location> --helm-chart-path <$TCSA_WORK_SPACE>/tcx-deployer/product-helm-charts/tcsa --values-file <$TCSA_WORK_SPACE>/tcx-deployer/product-helm-charts/tcsa/values.yaml --timeout <time-in-mins>
    After the deployment script exits, manually check the VMware Telco Cloud Service Assurance deployment status by running the following command from the deployment VM. 
    root [ ~/base/tcx-deployer/scripts ]# kubectl get tcxproduct 
 OR
root [ ~/base/tcx-deployer/scripts ]# kubectl get apps
    For all the apps, the reconciliation status must be successful. 
    root [ ~/base/tcx-deployer/scripts/deployment ]# kubectl get tcxproduct
NAME   STATUS            READY   MESSAGE                               AGE
tcsa   updateCompleted   True    All App CRs reconciled successfully   30h
    Note: After successful deployment, you can launch the VMware Telco Cloud Service Assurance UI. For more information, see Accessing VMware Telco Cloud Service Assurance UI topic. Ensure that the About page in the 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 Installation Issue in the VMware Telco Cloud Service Assurance Troubleshooting Guide.

After the upgrade, perform the actions listed in Post VMware Telco Cloud Service Assurance Upgrade topic.