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 CLI procedures as outlined in the following table.

Note:

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

Table 5-1 NRF Rollback Sequence

Rollback Sequence Applicable for CLI
Rollback Tasks 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
24.3.0 24.2.x
24.3.0 24.1.x

5.2 Rollback Tasks

To roll back from NRF 24.3.0 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.
  1. 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

  2. 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

  3. 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 24.3.0, then the rollback to 24.1.x, 24.2.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.