Rolling Back Policy

6 Rolling Back Policy

This chapter provides information about rolling back Oracle Communications Cloud Native Core, Converged Policy (Policy) deployment to the previous release. It is recommended to perform Policy rollback in a specific order. For more information about the rollback order, see Oracle Communications Cloud Native Core Solution Upgrade Guide.

Note:

In a multisite georedundant setup, perform the steps explained in this section on all georedundant sites separately.

6.1 Supported Rollback Paths

The following table lists the supported rollback paths for Policy:

Table 6-1 Supported Rollback Paths

Source Release	Target Release
26.1.201	25.2.2xx, 25.1.2xx

Note:

If georedundancy feature was disabled before upgrading to 26.1.201, then rolling back to a previous version will automatically disable this feature. However, the database will still have records of the NfInstances and NfSubscriptions from the mated sites. For more information, contact My Oracle Support.
On rollback, the Policy is supposed to go back to the same state (number of policies, configuration etc.) as before the upgrade.

6.2 Rollback Tasks

To roll back from Policy 26.1.201 to a previous version:

Note:

No configuration should be performed during rollback.
Do not exit from helm rollback command manually. After running the helm rollback command, it takes some time (depending upon number of pods to rollback) to rollback all of the services. In the meantime, you must not press "ctrl+c" to come out from helm rollback command. It may lead to anomalous behavior.
Ensure that no Policy pod is in the failed state.

Run the following command to check the revision you must roll back to:
```
helm history <release_name> -n <release_namespace>
```
Where,
- <release_name> is the release name used by the Helm command.
- <release_namespace> is the namespace where Policy is deployed.
For example:
```
helm history occnp --namespace occnp
```
In case of roll back from Policy 26.1.200 or above to Policy 25.2.2xx, perform the rollback tasks as explained in Rolling Back to Policy 25.2.2xx from Converged Policy 26.1.2xx or Later Versions.
If you are rolling back from Policy 23.2.4, perform the following tasks for audit registration to be successful and audit cycle to continue as expected:
1. Run the following command to find if JSON element "handleNullAsStale":false exists in audit_req_data column for a service.
```
select * from AuditRegistrations\G
```
2. If the JSON element exists, copy the JSON object string from column audit_reg_data and update it with the JSON element "handleNullAsStale":false or "handleNullAsStale":true element being removed and then use the updated JSON string for the column audit_reg_data in the below UPDATE command.
```
UPDATE occnp_audit_service.auditregistrations SET audit_req_data='{audit_req_data}' where service_name='{servicename}';
```
  {audit_req_data} should be the updated column data and {servicename} should be the value of the column service_name.
3. Run the following command to verify that the element is no longer in the JSON value.
```
select * from AuditRegistrations\G
```
4. Verify that the audit process is functioning as expected.

Run the command to rollback to the required revision:

helm rollback <release_name> <revision_number> --namespace <release_namespace>

Where, <revision_number> is the release number to which Policy needs to be rolled back.

For example:

helm rollback occnp 1 --namespace occnp

Note:

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


helm rollback <release-name> <revision_number> --namespace <release_namespace>
W0801 11:51:20.139886 3453570 warnings.go:70] spec.template.spec.containers[0].env[21]: hides previous definition of "PRRO_JDBC_SERVERS"
W0801 11:51:33.330235 3453570 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[1]
W0801 11:51:54.739481 3453570 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[2]
W0801 11:52:01.125243 3453570 warnings.go:70] spec.template.spec.containers[0].ports[4]: duplicate port definition with spec.template.spec.containers[0].ports[2]
W0801 11:52:05.530639 3453570 warnings.go:70] spec.template.spec.containers[0].ports[4]: duplicate port definition with spec.template.spec.containers[0].ports[2]
Rollback was a success! Happy Helming!

If the rollback fails, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Converged Policy Troubleshooting Guide.

6.2.1 Rolling Back to Policy 25.2.2xx from Converged Policy 26.1.2xx or Later Versions

This procedure applies only to converged Policy deployments in which the PCRF Core microservice is deployed.

If the value of kubeApiServerTlsVersion parameter in the Policy occnp_custom_values_26.1.201.yaml file is changed from TLSv1.2 to TLSv1.3 when upgrading Policy from a release earlier than 26.1.2xx to Policy 26.1.2xx, a subsequent rollback to Policy 25.2.201 can fail during the PCRF Core pre-rollback job.

In Policy 25.2.201, the PCRF Core deployment.yaml template contains two PRRO_JDBC_SERVERS environment-variable entries, which are used to connect to the database. In Policy 26.1.2xx and Policy 25.2.2xx and later, these duplicate entries were removed and replaced with a single PRRO_JDBC_SERVER environment variable.

After upgrading to Policy 26.1.2xx or later, the duplicate entries are removed from the deployment manifest. During a Helm rollback to Policy 25.2.2xx, the original duplicate entries are restored. Because stricter validation is applied when kubeApiServerTlsVersion is changed to TLSv1.3, the PCRF Core pre-rollback job can fail.

To roll back to a previously working Policy 25.2.2xx release, run:

helm rollback <release-name> <revision> -n <namespace> --force

Use the --force option so that Helm replaces the Kubernetes deployment instead of applying a patch. The rollback hooks run during this operation.