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.

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
25.2.201 25.1.2xx

5.2 Rollback Strategy

NRF supports in-service rollback. The supported rollback 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 rollback during maintenance window where the recommended traffic rate is 25% of the configured traffic or below. It is also expected the traffic failure to stay below 5% during the rollback and fully recover post rollback.

Following engineering configuration parameters are used to define rollback strategy:
  • upgradeStrategy parameter indicates the update strategy used in NRF.
  • maxUnavailable parameter determines the maximum number of pods that can be unavailable during rollback.

Table 5-3 Predefined Rollback Strategy Value

Microservice Rollback Value (maxUnavailabe)
ocnrf-nfregistration 25%
ocnrf-nfsubscription 25%
ocnrf-nfdiscovery 25%
ocnrf-nrfauditor 25%
ocnrf-nrfconfiguration Not Applicable

Note: maxSurge attribute is used for this microservice.

ocnrf-appinfo 25%
ocnrf-nfaccesstoken 25%
ocnrf-nrfartisan Not Applicable

Note: maxSurge attribute is used for this microservice.

ocnrf-alternate_route 25%
ocnrf-egressgateway 25%
ocnrf-ingressgateway 25%
ocnrf-performance 50%

Note:

<helm-release-name> is the Helm release name. For example, if Helm release name is "ocnrf", then nrfartisan microservice name will be "ocnrf-nrfartisan".

5.3 Rollback Tasks

To roll back from NRF 25.2.201 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 the target release, post upgrade the feature is enabled then when rollback is performed, the feature will be automatically disabled. However, the database will still have records of the NfInstances and NfSubscriptions from the mated sites. For deleting the records, contact My Oracle Support.

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