Deployment of Patch

You can deploy the patch by using the CLI, VMware Telco Cloud Automation UI, or the VM based deployment.

Deployment of Patch on VMware Tanzu Kubernetes Grid

Login to the Deployment Host and create a directory called patch under /root directory.
Download the patch bundle in the Deployment Host under the /root/patch directory.
Extract the downloaded patch bundle. Then set the workspace to the following directory path:
```
export TCSA_WORK_SPACE=/root/patch
```
Execute the upgradeTCSA.sh script located in $TCSA_WORK_SPACE/tcx-deployer/scripts.
For Self-signed certificates for Harbor, follow the below procedure:
- Copy the Harbor Certs file in /etc/ssl/certs.
- If you do not have permission to the directory /etc/ssl/certs, then put the Harbor Cert in any other location where you have access, and run the below command:
```
trust anchor <path-to-cert>
```
  - If trust command is not available, then install p11-kit-trust package which contains trust command.
Note: If you do not want to specify the registry user name and password in the installation script, perform Docker login. To login to Docker, run the following command:
```
docker login <harbor-fqdn>
```
Ensure that the --registry-password does not have the comma character in it. If the comma is used, escape it using the backslash.
Execute the upgradeTCSA.sh script.
```
root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/scripts
root [ ~/patch/tcx-deployer/scripts ]# ./upgradeTCSA.sh --kubeconfig <your-kubeconfig-location> --registry <harbor-registry-fqdn>/<project-name> --registry-password <harbor-registry-password> --registry-username <harbor-registry-username> --timeout <timeout in minute>
```
Note: You can specify 60 minutes for the timeout value. If there is any latency in the network, you can increase this value.
For example:
```
/root/patch/tcx-deployer/scripts/upgradeTCSA.sh --kubeconfig /root/.kube/config --registry 10.220.79.2/tcsa --registry-password <Harbor registry password> --registry-username admin --timeout 60
```
Note:
- The --registry <harbor-registry-fqdn>/<project-name> must be configured with the same value that is used during the base VMware Telco Cloud Service Assurance deployment.
- The --registry-cert is an optional parameter and must be provided in the above upgradeTCSA.sh script if the Harbor certificate is not a public certificate.
- If you do not want to specify the registry user name and password in the installation script, perform Docker login. To login to Docker, run the following command:
```
docker login <harbor-fqdn>
```
  Ensure that the --registry-password does not have the comma character in it. If the comma is used, escape it using the backslash.
Manually check the VMware Telco Cloud Service Assurance patch deployment status using the following command:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct
```
Alternatively, you can run the following command to check the patch deployment status:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
```
For all the apps, the reconciliation status must be successful.
Run the below post upgrade script, if the VMware Telco Cloud Service Assurance is an upgraded environment:
Note:
- If VMware Telco Cloud Service Assurance is upgraded from VMware Telco Cloud Service Assurance 2.1, 2.2 to 2.3 and then the Patch is applied, then the postUpgrade.sh script needs to be run.
- If the VMware Telco Cloud Service Assurance Patch is applied on 2.3 fresh deployment, then no need to run the postUpgrade.sh script.
```
root [ ~/patch/tcx-deployer/scripts ]# ./postUpgrade.sh <kubeconfig file location>
```
For example:
```
/root/patch/tcx-deployer/scripts/postUpgrade.sh  /root/.kube/config
```

Note: After the patch is deployed, you can view the patch versions in the About page of VMware Telco Cloud Service Assurance UI.

Deployment of Patch on AKS

Login to the Deployment Host and create a directory called patch under /root directory.
Download the patch bundle in the Deployment Host under the /root/patch directory.
Extract the downloaded patch bundle. Then set the workspace to the following directory path:
```
export TCSA_WORK_SPACE=/root/patch
```
Execute the upgradeTCSA.sh script located in tcx-deployer/scripts.
Execute the upgradeTCSA.sh script.
```
root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/scripts
root [ ~/patch/tcx-deployer/scripts ]# ./upgradeTCSA.sh --kubeconfig <your-kubeconfig-location> --registry <acr-registry-fqdn>/tcx --registry-password <acr-registry-password> --registry-username <acr-registry-username> --timeout <timeout in minute>
```
Note: You can specify 60 minutes for the timeout value. If there is any latency in the network, you can increase this value.
For example:
```
/root/patch/tcx-deployer/scripts/upgradeTCSA.sh --kubeconfig /root/.kube/config --registry <acr registry>/tcx --registry-password <acr registry password> --registry-username <acr registry user name> --timeout 60
```
Note: If you do not want to specify the registry user name and password in the installation script, perform Docker login. To login to Docker, run the following command:
```
docker login <acr-registry-fqdn>
```
Ensure that the --registry-password does not have the comma character in it. If the comma is used, escape it using the backslash.
Manually check the VMware Telco Cloud Service Assurance patch deployment status using the following command:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct
```
Alternatively, you can run the following command to check the patch deployment status:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
```
For all the apps, the reconciliation status must be successful.
Run the below post upgrade script, if the VMware Telco Cloud Service Assurance is an upgraded environment:
Note:
- If VMware Telco Cloud Service Assurance is upgraded from VMware Telco Cloud Service Assurance 2.1, 2.2 to 2.3 and then the Patch is applied, then the postUpgrade.sh script needs to be run.
- If the VMware Telco Cloud Service Assurance Patch is applied on 2.3 fresh deployment, then no need to run the postUpgrade.sh script.
```
root [ ~/patch/tcx-deployer/scripts ]# ./postUpgrade.sh <kubeconfig file location>
```
For example:
```
/root/patch/tcx-deployer/scripts/postUpgrade.sh  /root/.kube/config
```
Note: After the patch is deployed, you can view the patch versions in the About page of VMware Telco Cloud Service Assurance UI.

Deployment of Patch through VMware Telco Cloud Automation

Note: Before you start the patch deployment, make a note of all the input parameters which were specified as part of base VMware Telco Cloud Service Assurance deployment. This is required during the patch deployment process.

The previous input values can be found in VMware Telco Cloud Automation:

For VMware Telco Cloud Automation 2.2 or 2.3, navigate to VMware Telco Cloud Automation UI > Inventory > Network Function > VMware Telco Cloud Service Assurance Network Function Instance > Parameter.
For VMware Telco Cloud Automation 2.1.1, VMware Telco Cloud Automation UI > Inventory > Network Function > VMware Telco Cloud Service Assurance Network Function Instance > InitParams.

To deploy the patch using the VMware Telco Cloud Automation UI, perform the following steps:

Download the patch bundle in the Deployment Host under the /root/patch directory.
Extract the downloaded patch bundle. Then set the Workspace to the following directory path:
```
export TCSA_WORK_SPACE=/root/patch
```
For Self-signed certificates for Harbor, follow the below procedure:
- Copy the Harbor Certs file from Harbor VM to /etc/ssl/certs directory.
- If you do not have permission to the directory /etc/ssl/certs, then run the below command:
```
trust anchor <path-to-your-registry-ca-certificate-file>
```
  - If trust command is not available, then install p11-kit-trust package which contains trust command.
Push artifacts to the registry.
```
root [ ~/patch/tcx-deployer/clis ]# ./tcxctl push --artifacts-path $TCSA_WORK_SPACE/tcx-deployer/ --registry <harbor-registry-fqdn>/<project-name> --registry-password <your-registry-password> --registry-username <your-registry-username> --registry-cert <path-to-your-registry-ca-certificate-file>
```
Note:
- The --registry <harbor-registry-fqdn>/<project-name> must be configured with the same value that is used during the base VMware Telco Cloud Service Assurance deployment.
- The --registry-cert is an optional parameter and must be provided in the above tcxctl CLI if the Harbor certificate is not a public certificate.
- If you do not want to specify the registry user name and password in the installation script, perform Docker login. To login to Docker, run the following command:
```
docker login <harbor-fqdn>
```
  Ensure that the --registry-password does not have the comma character in it. If the comma is used, escape it using the backslash.

Deploy core component using the command:

root [ ~/patch/tcx-deployer/clis ]#./tcxctl deploy core --kubeconfig <your-kubeconfig-location> --registry <harbor-registry-fqdn>/<project-name> --tag-file $TCSA_WORK_SPACE/tcx-deployer/scripts/imgpkg_tags.yaml --registry-cert <path-to-your-registry-ca-certificate-file>

Note: Run the below, populateTcsaValuesYaml.sh scrip to get the previously configured VMware Telco Cloud Service Assurance base install parameters in values.yaml file. This can be used as a reference to fill the VMware Telco Cloud Service Assurance deployment parameters iin VMware Telco Cloud Automation UI during Patch upgrade.

root [ ~/patch/tcx-deployer/scripts ]# TCA_BASED_DEPLOYMENT=true;./populateTcsaValuesYaml.sh <your-kubeconfig-file-path>

Copy the tcsa-demo.csar or tcsa-production.csar depending on the demo footprint or production footprint, from the CSAR directory of the unpacked deployer package to your local machine used to access VMware Telco Cloud Automation.
```
root [ ~ ]# cd /root/patch/tcx-deployer/csars/
root [ ~ ]# pwd
/root/patch/tcx-deployer/csars
root [ ~ ]# ls
admin-operator.csar  tcsa-demo.csar  tcsa-init.csar  tcsa-production.csar
root [ ~ ]#
```
After the CSAR is copied, launch VMware Telco Cloud Automation, navigate to Catalog > Network Function and click Onboard Network Function. Onboard the CSAR demo or production footprint files that are copied. Provide a name while onbarding the CSAR. The same CSAR name must be selected during patch upgrade.
Navigate to Inventory > Network Function, click the three dots against the CNF to upgrade as part of the patch, and select Upgrade.
In the Upgrade Revision section, select the new CSAR file that you onboarded. Click Next.
In the Components section, click Next.
In the Inventory Detail section, ensure that the Namespace is set to default and select the registry URL<oci://<registryRootUrl> endpoint of the associated, and click Next.
Note: The registryRootUrl must be set to the same value as the --registry-url parameter of the installer script in the Push Artifacts to Registry topic.
In the Inputs section, update the following parameters:
Note: You can refer the output of populateTcsaValuesYaml.sh which was executed in Step5, to update the Input parameters.
- The registryRootUrl must be set to the same value as the --registry-url parameter of the installer script in the Push Artifacts to Registry topic.
- For dashboardAccess, set the ip and type to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
- Set footprint same as the base version.
- (Optional) Set edgeServicesAccessIp to the same value specified during the base VMware Telco Cloud Service Assurance deployment.
- Set flexible configuration parameters to the same value specified during the base VMware Telco Cloud Service Assurance deployment. For more information, see VMware Telco Cloud Service Assurance through VMware Telco Cloud Automation Instantiation for Production Footprint for production footprint and for demo footprint refer the Instantiation for Demo Footprint topic.
- All the Backup and Restore values must be same as specified during the base VMware Telco Cloud Service Assurance deployment.
- Click Next.
The Network Function Properties page appears. Click Next.
In the Review section, click Upgrade.
Once the patch upgrade is successful, verify the patch deployment status by logging on to the deployment VM and running the following kubectl command:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct 
OR
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
```
For all the apps, the reconciliation status must be successful.
Run the below post upgrade script, if the VMware Telco Cloud Service Assurance is an upgraded environment:
Note:
- If VMware Telco Cloud Service Assurance is upgraded from VMware Telco Cloud Service Assurance 2.1, 2.2 to 2.3 and then the Patch is applied, then the postUpgrade.sh script needs to be run.
- If the VMware Telco Cloud Service Assurance Patch is applied on 2.3 fresh deployment, then no need to run the postUpgrade.sh script.
```
root [ ~/patch/tcx-deployer/scripts ]# ./postUpgrade.sh <kubeconfig file location>
```
For example:
```
/root/patch/tcx-deployer/scripts/postUpgrade.sh  /root/.kube/config
```
Note: After the patch is deployed, you can view the patch versions in the About page of VMware Telco Cloud Service Assurance UI.
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.

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

Login to the Deployment Host and create a directory called patch under /root directory.
Download the patch bundle in the Deployment Host under the /root/patch directory.
Extract the downloaded patch bundle. Then set the workspace to the following directory path:
```
export TCSA_WORK_SPACE=/root/patch
```
Execute the upgradeTCSA.sh script located in $TCSA_WORK_SPACE/tcx-deployer/scripts.
For Self-signed certificates for Harbor, follow the below procedure:
- Copy the Harbor Certs file from /etc/docker/certs.d/<Harbro-IP>/ca.crt to /etc/ssl/certs directory.
- If you do not have permission to the directory /etc/ssl/certs, then run the below command:
```
trust anchor /etc/docker/certs.d/<Harbor-IP>/ca.crt
```
  - If trust command is not available, then install p11-kit-trust package which contains trust command.
Note: If you do not want to specify the registry user name and password in the installation script, perform Docker login. To login to Docker, run the following command:
```
docker login <harbor-fqdn>
```
Ensure that the --registry-password does not have the comma character in it. If the comma is used, escape it using the backslash. The default Harbor registry password is TCXAdmin123 and default Harbor user name is admin.
Execute the upgradeTCSA.sh script.
```
root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/scripts
root [ ~/patch/tcx-deployer/scripts ]# ./upgradeTCSA.sh --kubeconfig <your-kubeconfig-location> --registry <harbor-registry-fqdn>/tcx --registry-cert /etc/docker/certs.d/<Harbor-IP>/ca.crt  --registry-password <harbor-registry-password> --registry-username <harbor-registry-username> --timeout <timeout in minute>
```
Note: You can specify 60 minutes for the timeout value. If there is any latency in the network, you can increase this value.
For example:
```
/root/patch/tcx-deployer/scripts/upgradeTCSA.sh --kubeconfig /root/.kube/vmbased-oracle-vsan-Longevity-2 --registry 10.220.79.2/tcx --registry-cert /etc/docker/certs.d/10.220.79.2/ca.crt  --registry-password TCXAdmin123 --registry-username admin --timeout 60
```
Manually check the VMware Telco Cloud Service Assurance patch deployment status using the following command:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct
```
Alternatively, you can run the following command to check the patch deployment status:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
```
For all the apps, the reconciliation status must be successful.

Note: After the patch is deployed, you can view the patch versions in the About page of VMware Telco Cloud Service Assurance UI.

Deployment of Patch on EKS

Login to the Deployment Host and create a directory called patch under /root directory.
Download the patch bundle in the Deployment Host under the /root/patch directory.
Extract the downloaded patch bundle. Then set the workspace to the following directory path:
```
export TCSA_WORK_SPACE=/root/patch
```

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

Execute the upgradeTCSA.sh script.
```
export AWS_PROFILE=<profileid>
```
```
root [ ~ ]# cd $TCSA_WORK_SPACE/tcx-deployer/scripts
root [ ~/patch/tcx-deployer/scripts ]# ./upgradeTCSA.sh --kubeconfig <your-kubeconfig-location> --registry <your-profile-ID>.dkr.ecr.<aws-region>.amazonaws.com/<project-name>  --timeout <timeout in minute>
```
Note: You can specify 60 minutes for the timeout value. If there is any latency in the network, you can increase this value.
For example:
```
/root/patch/tcx-deployer/scripts/upgradeTCSA.sh --kubeconfig /root/.kube/config --registry <your-profile-ID>.dkr.ecr.us-west-2.amazonaws.com/<project-name> --timeout 60
```
Note: The --registry <your-profile-ID>.dkr.ecr.<aws-region>.amazonaws.com/<project-name> must be configured with the same value that is used during the base VMware Telco Cloud Service Assurance deployment.
Manually check the VMware Telco Cloud Service Assurance patch deployment status using the following command:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get tcxproduct
```
Alternatively, you can run the following command to check the patch deployment status:
```
root [ ~/patch/tcx-deployer/scripts ]# kubectl get apps
```
For all the apps, the reconciliation status must be successful.
Run the below post upgrade script, if the VMware Telco Cloud Service Assurance is an upgraded environment:
Note:
- If VMware Telco Cloud Service Assurance is upgraded from VMware Telco Cloud Service Assurance 2.1, 2.2 to 2.3 and then the Patch is applied, then the postUpgrade.sh script needs to be run.
- If the VMware Telco Cloud Service Assurance Patch is applied on 2.3 fresh deployment, then no need to run the postUpgrade.sh script.
```
root [ ~/patch/tcx-deployer/scripts ]# ./postUpgrade.sh <kubeconfig file location>
```
For example:
```
/root/patch/tcx-deployer/scripts/postUpgrade.sh  /root/.kube/config
```
Note: After the patch is deployed, you can view the patch versions in the About page of VMware Telco Cloud Service Assurance UI.