Upgrading Policy

5 Upgrading Policy

This chapter provides information about upgrading Oracle Communications Cloud Native Core, Converged Policy (Policy) deployment to the latest release.

It is recommended to perform Policy upgrade in a specific order.

For more information about the upgrade order, see Oracle Communications Cloud Native Core, Solution Upgrade Guide.

Note:

Before starting the CNC Console installation or upgrade, ensure that the cnDBTier across all sites is updated with the latest maximum limit values for:
- MaxNoOfTables
- MaxNoOfAttributes
- MaxNoOfOrderedIndexes
- MaxNoOfUniqueHashIndexes
These numbers are part of the cnDBTier yaml file shared with the release package. This is required to ensure that before application and CNC Console gets upgraded to the new release, cnDBTier supports the maxlimits required.
Before starting the CNC Console installation or upgrade, ensure that the cnDBTier across all sites is updated with the latest maximum limit values. These numbers are part of the cnDBTier yaml file shared with the release package. This is required to ensure that the before upgrade to the new release cnDBTier supports the maxlimits required.
Unless otherwise stated, features should not be enabled during Policy upgrade using Helm. It is recommended to enable new features only after ensuring that the Policy upgrade is successful and a rollback to an older release will not be considered. In a multi-site environment, Policy upgrade must be successful in all the sites before enabling the required features. This can involve two Helm upgrades: one for upgrading Policy software version and then another Helm upgrade to enable the feature after accepting the upgrade.
If there are any issues observed after enabling the features, disable the feature using Helm and CNC Console, perform a Helm upgrade, and verify that the issue is resolved.

Note:

In a georedundant deployment, perform the steps explained in this section on all the georedundant sites.
For Policy georedundant deployments, all the georedundant sites are expected to be upgraded to the common version before any individual site of GR deployment is planned for additional upgrade.

For example, In a three-site Policy deployment, all the 3 sites are at the same release version as N. During site upgrade, site 1 and site 2 are upgraded to N+1 version, and site 3 is not upgraded yet. At this state, before upgrading site 3 to N+1/N+2, upgrading site 1 or site 2 from N+1/N+2 version to higher version is not supported as site3 in the georedundant environment is still not upgraded to N+1/N+2.

For more information about the cnDBTier georedundant deployments, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

For more information about the CNC Console georedundant deployments, see Oracle Communications Cloud Native Core, CNC Console Installation, Upgrade, and Fault Recovery Guide.

5.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for Policy:

Table 5-1 Supported Upgrade Paths

Source Release	Target Release
25.2.2xx, 25.1.2xx	26.1.201

Note:

Upgrade from 25.1.2xx to 26.1.200 is only aplicable in ASM deployments.
Policy must be upgraded before upgrading cnDBTier.

5.2 Upgrade Strategy

Policy supports in-service upgrade. The supported upgrade strategy is RollingUpdate. The rolling update strategy is a gradual process that allows you to update your Kubernetes system with only a minor effect on performance and no downtime. The advantage of the rolling update strategy is that the update is applied Pod-by-Pod so the greater system can remain active.

Note:

It is recommended to perform in-service upgrade during maintenance window where the recommended traffic rate is 25% of the configured traffic or below. We also expect the traffic failure to stay below 5% during the upgrade and fully recover post upgrade.

The following engineering configuration parameters are used to define upgrade strategy:

upgradeStrategy parameter indicates the update strategy used in Policy.
maxUnavailable parameter determines the maximum number of pods that will be unavailable during upgrade.
For more information on maxUnavailable for each microservices
refer PodDisruptionBudget Configuration section.

Note:

When Policy is deployed with OCCM, follow the specific upgrade sequence as mentioned in the Oracle Communications, Cloud Native Core Solution Upgrade Guide.

Note:

During an in-service Helm upgrade transient errors may occur which are typically resolved by the Network Element's retry mechanism. It is done either by using a different available pod on the same site or by retrying at another site.

It is recommended to execute in-service Helm upgrade during maintenance window or low traffic period to minimize any service impact.

5.3 Preupgrade Tasks

This section provides information about preupgrade tasks to be performed before upgrading Policy.

Keep current custom_values.yaml file as backup.
Update the new custom_values.yaml file for target Policy release. For details on customizing this file, see Customizing Policy.
To add or drop an index at site level, configure the value of performAddDropIndexAtSiteLevel parameter to TRUE in custom_values.yaml file. For more details on this parameter, see Configurations for Pre and Post Upgrade/Install Validations.
Provide the following privileges to occnpadminusr:
```
mysql -h 127.0.0.1 -u<root user> -p<root password>
```
```
GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'occnpadminusr'@'%' WITH GRANT OPTION;
```

Remove the following index keys from contexbinding table. as they are not required:

idx_dnn
idx_domain
idx_sd
idx_sst

ReleaseHelmHook_26.1.201.java automatically checks and drops the above indexes from the contextbinding table if they exist.

Make sure that the database user has the required permission before the upgrade procedure, as the index drop flow may need site-level sql_log_bin handling.

GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'occnpadminusr'@'%' WITH GRANT OPTION;

If the automated index drop fails during upgrade procedure, perform the following steps manually to drop the indexes.

Move the site to control shutdown state.
Log in to one of the ndbappmysqld pods on the site where the index drop activity is being performed.
```
kubectl -n <namespace> exec -it pod/ndbappmysqld-0 -- mysql -h127.0.0.1 -uroot -p<password>
```

Verify that the required Binding Service indexes are present on the local site:

mysql> USE <binding-database>;
mysql> SHOW CREATE TABLE contextbinding;
-- STEP 0: Check if idx_dnn, idx_domain, idx_sd, idx_sst are present

Check for the presence of specific indexes:

-- Verify idx_dnn index (STEP1)
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_dnn';

-- Verify idx_domain index (STEP2)
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_domain';

-- Verify idx_sd index (STEP3)
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_sd';

-- Verify idx_sst index (STEP4)
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_sst';

Note:

Confirm that the results are either Exist or Not Exist.

Verify if idx_dnn is present and compare it with the output of the above step. Both are expected to have the same value.
Verify if idx_domain is present and compare it with the output of the above step. Both are expected to have the same value.
Verify if idx_sd is present and compare it with the output of the above step. Both are expected to have the same value.
Verify if idx_sst is present and compare it with the output of the above step. Both are expected to have the same value.

Perform Index drop operations:
1. Disable binary logging for the current session to avoid performance impact during index modifications:
```
mysql> SHOW VARIABLES LIKE 'sql_log_bin';
mysql> SET sql_log_bin = OFF; -- Disables binary logging for this session only
mysql> SHOW VARIABLES LIKE 'sql_log_bin';
```
  Note:
  - Binary logging is disabled only for the current session. Do not exit this session until all the drop index operations are complete. If exited, ensure to disable it again in the new session.
  - To update the sql_log_bin variable, make sure that the below permission is granted to the user:
    GRANT SYSTEM_VARIABLES_ADMIN ON *.* TO 'occnpadminusr'@'%' WITH GRANT OPTION;
  Switch to the target database: mysql> USE <binding-database>;
```
mysql> USE <binding-database>;
```
2. If any of the above mentioned indexes are present in contextBinding table, perform the following ALTER TABLE commands:
```
-- If idx_dnn exists in STEP1, drop the index
mysql> ALTER TABLE contextbinding DROP INDEX idx_dnn, ALGORITHM=INPLACE;

-- If idx_domain exists in STEP2, drop the index
mysql> ALTER TABLE contextbinding DROP INDEX idx_domain, ALGORITHM=INPLACE;

-- If idx_sd exists in STEP3, drop the index
mysql> ALTER TABLE contextbinding DROP INDEX idx_sd, ALGORITHM=INPLACE;

-- If idx_sst exists in STEP4, drop the index
mysql> ALTER TABLE contextbinding DROP INDEX idx_sst, ALGORITHM=INPLACE;
```
  Note:
  These operations can take some time depending on traffic and database size. Since the site is traffic-isolated and binary logging is disabled, performance and latency on other sites will not be affected.
Re-enable binary logging after operations are complete:
```
mysql> SHOW VARIABLES LIKE 'sql_log_bin';
mysql> SET sql_log_bin = ON;
mysql> SHOW VARIABLES LIKE 'sql_log_bin';
```
Note:

While executing the above DDL statements, there can be call failures for a couple of minutes during this activity due to timeouts or deadlocks in the respective site. It should not impact traffic on other sites.

To avoid call failures, it is advised to move the site to control shutdown state.

Verify that the indexes are dropped:

-- Verify idx_dnn index - Not Exist
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_dnn';

-- Verify idx_domain index - Not Exist
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_domain';

-- Verify idx_sd index - Not Exist
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_sd';

-- Verify idx_sst index - Not Exist
mysql> SELECT IF(COUNT(*) = 1, 'Exist', 'Not Exist') AS result FROM information_schema.statistics WHERE TABLE_SCHEMA = '<binding-database>' AND TABLE_NAME = 'contextbinding' AND INDEX_NAME = 'idx_sst';

Optionally, verify the indexes present in contextBining table.
```
SHOW CREATE TABLE contextbinding
```
Exit from the mysql prompt.
```
mysql> exit
```
Repeat the above steps on subsequent sites after successful completion on one site.

Before starting the upgrade, take a manual backup of Policy REST based configuration. This helps if preupgrade data has to be restored.

Note:
For Rest API configuration details, see Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.
Before upgrading, perform sanity check using Helm test. See the Performing Helm Test section for the Helm test procedure.
Before starting the Helm upgrade to the latest NF version, please check the set of required databases from Configuring Database, Creating Users, and Granting Permissions section to ensure if they have to be common or site specific. If any of the required databases from Configuring Database, Creating Users, and Granting Permissions section are not available, then ensure adding the missing databases before proceeding with the upgrade.

5.4 Upgrade Tasks

This section provides information about the sequence of tasks to be performed for upgrading an existing Policy deployment.

Helm Upgrade

Upgrading an existing deployment replaces the running containers and pods with new containers and pods. If there is no change in the pod configuration, it is not replaced. Unless there is a change in the service configuration of a microservice, the service endpoints remain unchanged.

Upgrade Procedure

Caution:

Stop the provisioning traffic before you start the upgrade procedure.
Do not perform any configuration changes during the upgrade.
Do not exit from helm upgrade command manually. After running the helm upgrade command, it takes some time (depending upon the number of pods to upgrade) to upgrade all the services. In the meantime, you must not press "ctrl+c" to come out from helm upgrade command. It may lead to anomalous behavior.

Note:

While upgrading from Policy 25.2.2xx to 26.1.200, you are not required to perform a double upgrade, as the duplicate port issue is resolved starting from these versions. However, while upgrading from 25.2.1xx or any earlier version to 26.1.200, you should run the Helm upgradetwice in order to fully eliminate a duplicate container port definition condition (that is, duplicate port 9000). The second upgrade must run with the Helm flag --no-hooks.
After the first upgrade, you may not see service/pod metrics for the impacted Policy services—usage-mon, user-service (UDR, CHF), and queryservice—as well as the impacted BSF services—BSF and queryservice. However, after the second upgrade, metrics for all previously affected Policy and BSF services should be visible again.

Untar the latest Policy package and if required, re-tag and push the images to registry. For more information, see Downloading Policy package and Pushing the Images to Customer Docker Registry.
Modify the occnp_custom_values_26.1.201.yaml file parameters as per site requirement.
Do not change the nfInstanceId configuration for the site. In case of multisite deployments, configure nfInstanceId uniquely for each site.
Assign appropriate values to core_services in the appInfo configuration based on policy Mode.
Run the following command to upgrade an existing Policy deployment:

Note:
If you are upgrading an existing Policy deployment with georedundancy feature enabled, ensure that you configure dbMonitorSvcHost and dbMonitorSvcPort parameters before running helm upgrade. For more information on the parameters, see
- Using local Helm chart:
```
helm upgrade <release_name> <helm_chart> -f <occnp_customized_values.yaml> --namespace <namespace>
```
  Where,
  
  <release_name> is the Policy release name.
  
  <helm_chart> is the Helm chart.
  
  <policy_customized_values.yaml> is the latest custom-values.yaml file. For example, occnp_custom_values_26.1.201.yaml
  
  <namespace> is namespace of Policy deployment.
  
  For example:
```
helm upgrade occnp occnp-26.1.201.0.0.tgz -f occnp_custom_values_26.1.201.yaml --namespace occnp
```
- Using chart from Helm repo:
```
helm upgrade <release_name> <helm_repo/helm_chart> --version <chart_version> -f <policy_customized_values.yaml> --namespace <namespace>
```
  Where,
  
  <release_name> is the Policy release name.
  
  <helm_repo/helm_chart> is the Helm repository for Policy.
  
  <policy_customized_values.yaml> is the latest custom-values.yaml file. For example, occnp-26.1.201-custom-values-occnp.yaml
  
  <namespace> is namespace of Policy deployment.
  
  For example:
```
helm upgrade occnp occnp-helm-repo/occnp --version 26.1.201 -f occnp_custom_values_26.1.201.yaml --namespace occnp
```
Optional parameters that can be used in the helm upgrade command:
- atomic:If this parameter is set, installation process purges chart on failure. The --wait flag will be set automatically.
- wait: If this parameter is set, installation process will wait until all pods, PVCs, Services, and minimum number of pods of a deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout.
- timeout duration: If not specified, default value will be 300 (300 seconds) in Helm. It specifies the time to wait for any individual Kubernetes operation (like Jobs for hooks). If the helm install command fails at any point to create a Kubernetes object, it will internally call the purge to delete after the timeout value. Here, the timeout value is not for overall installation, but for automatic purge on installation failure.
Note:
It is recommended not to use --wait and --atomic parameters along with helm upgrade as this might result in upgrade failure.

Run helm upgrade again with --no-hooks to upgrade an existing Policy deployment:

helm upgrade <release-name> <helm_chart> -f <occnp_customized_values.yaml> --namespace <namespace> --no-hooks

Run the following command to check the status of the upgrade:
```
helm status <release_name> --namespace <namespace>
```
Where,

<release_name> is the Policy release name.

<namespace> is namespace of Policy deployment.

For example:
```
helm status occnp --namespace occnp
```
Perform sanity check using Helm test. See the Performing Helm Test section for the Helm test procedure.
If the upgrade fails, see "Upgrade or Rollback Failure" in Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.

Note:

If you are upgrading from any of the previous releases to Policy 25.1.200 or later versions, after the upgrade procedure is complete, clear the browser cache before accessing the CNC Console, to avoid any configuration-related issues.

Note:

The following warnings must be ignored for policy upgrade on CNE 25.1.2xx and 25.2.1xx:

helm upgrade <release-name> -f <custom.yaml> <tgz-file> -n <namespace>
W0301 15:46:11.144230 2082757 warnings.go:70] spec.template.spec.containers[0].env[21]: hides previous definition of "PRRO_JDBC_SERVERS"
W0301 15:46:48.202424 2082757 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[1]
W0301 15:47:25.069699 2082757 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[2]
W0301 15:47:43.260912 2082757 warnings.go:70] spec.template.spec.containers[0].ports[4]: duplicate port definition with spec.template.spec.containers[0].ports[2]
W0301 15:47:51.457088 2082757 warnings.go:70] spec.template.spec.containers[0].ports[4]: duplicate port definition with spec.template.spec.containers[0].ports[2]
Release "<release-name>" has been upgraded. Happy Helming!
NAME: <release-name>
LAST DEPLOYED: <Date-Time>
NAMESPACE: <namespace>
STATUS: deployed
REVISION: <N>

After Upgrade, Congestion Control Data Migration

The Diameter Gateway Pod Congestion Control, and Bulwark Pod Congestion Control features are modified to work with common Congestion Control mechanism in 25.1.200. Due to which there are changes to the configurations and would require a data migration. After performing upgrade to 25.1.200, the user need to perform data migration from older Congestion Control configurations to the current configurations. The data migration process is manual and one-time activity that user has to perform, by using either the CNC Console or Congestion Control migration APIs.

For more information about the data migration, see "Diameter Pod Congestion Control" feature description and Congestion Control "settings" sections in Oracle Communications Cloud Native Core, Converged Policy User Guide.

For more information about the data migration, see "Bulwark Pod Congestion Control" feature description and Congestion Control "settings" sections in Oracle Communications Cloud Native Core, Converged Policy User Guide.

For more information about the data migration using the REST API, see "Diameter Gateway Congestion Migration" API section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

For more information about the data migration using the REST API, see "Bulwark Congestion Migration" API section in Oracle Communications Cloud Native Core, Converged Policy REST Specification Guide.

Note:

If Usage Monitoring Service is enabled during upgrade to 24.2.1, then the log level must be set to WARN in the CNC Console for the Usage Monitoring Service.

Note:

To automate the life cycle management of the certificates through OCCM, you can migrate certificates and keys from Policy to OCCM. For more information, see "Introducing OCCM in an Existing NF Deployment" in Oracle Communications Cloud Native Core, Certificate Management User Guide.

You can remove Kubernetes secrets if the current version of Policy does not use that secret by checking the occnp_custom_values.yaml file. Before deleting, please make sure that there is no plan to rollback to the Policy version which uses these secrets. Otherwise Rollback will fail.

After the upgrade http_server_requests_seconds metric with dimension {pod=~".*ueservice.*}" for UE service is replaced with occnp_ueservice_overall_processing_time_seconds and http_server_requests_seconds metric with dimension {pod=~".*amservice.*}" for AM service is replaced with occnp_amservice_overall_processing_time_seconds. Make sure to use the new metrics:

For UE service:
- occnp_ueservice_overall_processing_time_seconds_max instead of http_server_requests_seconds_max
- occnp_ueservice_overall_processing_time_seconds_sum instead of http_server_requests_seconds_sum
- occnp_ueservice_overall_processing_time_seconds_count instead of http_server_requests_seconds_count
For AM service:
- occnp_amservice_overall_processing_time_seconds_max instead of http_server_requests_seconds_max
- occnp_amservice_overall_processing_time_seconds_sum instead of http_server_requests_seconds_sum
- occnp_amservice_overall_processing_time_seconds_count instead of http_server_requests_seconds_count

For more details, see UE Service Metrics and AM Service Metrics sections in Oracle Communications Cloud Native Core, Converged Policy User Guide.

5.5 MIB Management

toplevel.mib and POLICY-ALARM-MIB.mib are two MIB files which are used to generate the traps. You must update these files along with the Alert file in order to fetch the traps in their environment. The MIB files are managed by SNMP manager.

Note:

policy-alarm-mib.mib file has been replaced by POLICY-ALARM-MIB.mib file.

5.6 Migrating Policy to Support an ASM Disabled cnDBTier

Perform the following procedure to migrate Policy to connect with cnDBTier without ASM (mTLS):

Prerequisites

Ensure that Policy is deployed with ASM enabled.
cnDBTier is deployed with istioSidecarInject.mode parameter set to all.
Perform complete CNC solution upgrade to 26.1.200 as per sequence defined in Oracle Communications Cloud Native Core, Solution Upgrade Guide. cnDBTier upgrade has to be done with the istioSidecarInject.mode parameter set to all.

Note:
In-service upgrade is not supported for migrating from an ASM-enabled cnDBTier configuration to one that removes ASM from internal communication while retaining ASM only for external communication. You must first divert traffic to another site, then isolate the current site from georeplication before making any change. Later the site being migrated needs to be put in COMPLETE SHUTDOWN state by using CNC Console (POLICY --> Controlled Shutdown --> Operational State).

Migrate cnDBTier deployment to one with the istioSidecarInject.mode parameter set to external.
This deployment should have sidecar injected only in the pods used for external communication after migration. For more information about the migration procedure, see "Migrating cnDBTier to Use ASM for External Communication" in Oracle Communications Cloud Native Core, cnDBTier User Guide .
Ensure that the DestinationRule is present in the occnp_servicemesh_config_values_26.1.200.yaml file. For more information about updating the DestinationRule, see step 3 in the Installing Service Mesh Configuration Charts section.
Run the following command to upgrade occnp-servicemesh-config with the updated occnp_servicemesh_config_values_26.1.200.yaml file:
```
helm upgrade <servicemesh_release_name> <charts> --namespace occnp -f <service_mesh_custom_values.yaml file>
```
Note:
If the DestinationRule being updated by the Service Mesh Helm release already exists and has been manually modified (for example, using kubectl edit or kubectl patch), helm upgrade may not reconcile all fields in the existing resource. If the updated configuration is reflected correctly after the upgrade, no further action is required and this Note can be ignored. However, if the expected configuration is not applied, delete the affected DestinationRule and rerun the Helm upgrade so that Helm recreates it with the desired specification.
Verify the connection between Policy microservices and cnDBTier to ensure that all pods are up and running after the migration.
Run the following command to perform Helm test to check the state of the deployments:
```
helm test occnp -n  <namespace> --logs
```
No error logs should be present in the output of this command.
Restore the traffic back to this Policy site after doing sanity checks.
Repeat the same procedure for the other sites in the georedundant setup.

5.6.1 Reverting to mTLS

Perform the following procedure to migrate Policy to connect with cnDBTier with ASM (mTLS). Here cnDBTier istioSidecarInject.mode is going to be set to all. Perform this procedure to revert the disabling mTLS procedure outlined above.

Prerequisites

Ensure the environment is currently deployed with: istioSidecarInject.mode set to external which was migrated earlier as part of disabling mTLS procedure.

Note:
In-service upgrade is not supported for migrating from a cnDBTier configuration that uses ASM only for external communication to one that enables ASM for both internal and external communication. You must first divert traffic to another site, then isolate the current site from georeplication before making any change. Later, the site being migrated must be put into COMPLETE SHUTDOWN state using the CNC Console (POLICY → Controlled Shutdown → Operational State).

Migrate cnDBTier deployment to one with the istioSidecarInject.mode parameter set to all.
This deployment should have sidecar injected only in the pods used for both internal and external communication after the migration. For more information about the migration procedure, see "Migrating cnDBTier to Use ASM for External Communication" in Oracle Communications Cloud Native Core, cnDBTier User Guide .
Ensure that the DestinationRule corresponding to the all deployment mode is present in the occnp_servicemesh_config_values_26.1.200.yaml file. For more information about updating the DestinationRule, see step 3 in the Installing Service Mesh Configuration Charts section.
Run the following command to upgrade occnp-servicemesh-config with the updated occnp_servicemesh_config_values_26.1.200.yaml file:
```
helm upgrade <servicemesh_release_name> <charts> --namespace occnp -f <service_mesh_custom_values.yaml file>
```
Note:
If the DestinationRule being updated by the Service Mesh Helm release already exists and has been manually modified (for example, using kubectl edit or kubectl patch), helm upgrade may not reconcile all fields in the existing resource. If the updated configuration is reflected correctly after the upgrade, no further action is required and this Note can be ignored. However, if the expected configuration is not applied, delete the affected DestinationRule and rerun the Helm upgrade so that Helm recreates it with the desired specification.
Verify the connection between Policy microservices and cnDBTier to ensure that all pods are up and running after the migration and that communication over both internal and external interfaces is functioning correctly.
Run the following command to perform Helm test to check the state of the deployments:
```
helm test occnp -n  <namespace> --logs
```
No error logs should be present in the output of this command.
Restore the traffic back to this Policy site after completing the sanity checks.
Repeat the same procedure for the other sites in the georedundant setup.