5 Rolling Back NSSF

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

Note:

  • It is recommended to perform in-service rollback in 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 rollback and fully recover post rollback.
  • In a multisite georedundant setup, perform the steps explained in this section on all georedundant sites separately.

5.1 Supported Rollback Paths

Caution:

In a georedundant scenario, If the replication channel(s) go down between NSSF sites' databases, follow the recovery procedure explained in the sections, "Resolving Georeplication Failure Between cnDBTier Clusters in a Two Site Replication" and "Resolving Georeplication Failure Between cnDBTier Clusters in a Three Site Replication " in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide to recover the replication.

The following table lists the supported rollback paths for Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF):

Table 5-1 Supported Rollback Paths

Source Release Target Release
25.1.201 25.1.200, 25.1.1xx

5.2 Rollback Tasks

To roll back from NSSF 25.1.201 to a previous version:

Caution:

  • 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 NSSF pod is in the failed state.
  1. 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 NSSF is deployed.

    For example:

    helm history ocnssf --namespace ocnssf
  2. 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 NSSF needs to be rolled back.

    For example:

    helm rollback ocnssf 1 --namespace ocnssf
  3. If the rollback fails, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.

5.3 Postrollback Tasks

After performing rollback, restore preupgrade data obtained earlier through manual backup.

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

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