Rolling Back NRF

5 Rolling Back NRF

This chapter provides information about rolling back Oracle Communications Cloud Native Core, Network Repository Function (NRF) deployment to previous version using CDCS or CLI procedures as outlined in the following table.

Note:

While performing a cnDBTier rollback to 23.2.x versions, cnDBTier uses the mysql_native_password authentication plugin for altering the users. Use the following commands for altering the users before performing a roll back if the authentication plugin in use is caching_sha2_password:
```
ALTER USER IF EXISTS 'nrfPrivilegedUsr'@'%' IDENTIFIED WITH 'mysql_native_password' BY
      'nrfPrivilegedPasswd';
ALTER USER IF EXISTS 'nrfApplicationUsr'@'%' IDENTIFIED WITH 'mysql_native_password' BY
      'nrfApplicationPasswd';
```
In a georedundant deployment, perform the steps explained in this section on all georedundant sites separately.

Table 5-1 NRF Rollback Sequence

Rollback Sequence	Applicable for CDCS	Applicable for CLI
Rollback Tasks	See Oracle Communications CD Control Server User Guide	Yes

5.1 Supported Rollback Paths

The following table lists the supported rollback paths for NRF.

Table 5-2 Supported Rollback Paths

Source Release	Target Release
23.4.6	23.4.x
23.4.6	23.3.x

5.2 Rollback Tasks

To roll back from NRF 23.4.6 to previous release:

Caution:

Do not perform any configuration changes during the rollback.
Do not exit from the helm rollback command manually. After running the helm rollback command, it takes sometime (depending upon the number of PODs to rollback) to rollback all of the services. Do not press "ctrl+c" to come out from the helm rollback command. It may lead to anomalous behavior.

Check which revision you need to roll back by running the following command:
```
$ 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 NRF is deployed.

For example:

helm history ocnrf --namespace ocnrf
Rollback to the required revision:
```
$ helm rollback <release_name> <revision_number> -n <release_namespace>
```
Where,

<release_name> is the release name used by the Helm command.

<revision_number> is the revision number.

<release_namespace> is the namespace where NRF is deployed.

For example:

$ helm rollback ocnrf 1 -n ocnrf
If the rollback fails, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Network Repository Function Troubleshooting Guide.

Note:

If georedundancy feature was disabled before upgrading to 23.4.6, then the rollback to 23.3.x or 22.4.x will automatically disable the feature. However, the database will still have records of the NfInstances and NfSubscriptions from the mated sites. For deleting the records, contact My Oracle Support.
Before rollback, disable Subscription limit feature on all georedundant sites, if enabled.
If you do not disable, the OcnrfSubscriptionMigrationInProgressCritical alert raised.

5.3 Postrollback Steps

After performing rollback to the same release, restore preupgrade data obtained earlier through manual backup.

GET API for different resources can be used to see current values in NRF, then accordingly if any update required, individual service APIs defined for different resources can be used to reconfigure the data backup taken before upgrade.

Note:

Post rollback, the NfInstances table continue to have the nfProfileUpdateTimestamp column in its schema. The schema change is back ward compatible, hence the older version continues to service without any impact.

See Oracle Communications Cloud Native Core, Network Repository Function REST Specification Guide for API details.