Upgrading NSSF

4 Upgrading NSSF

This chapter provides information about upgrading Oracle Communications Cloud Native Core, Network Slice Selection Function (NSSF) deployment to the latest release. It is recommended to perform NSSF upgrade in a specific order. For more information about the upgrade 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 the georedundant sites.

4.1 Supported Upgrade Paths

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

Table 4-1 Supported Upgrade Paths

Source Release	Target Release
23.4.x	24.1.1

Note:

In case of georedundant deployment, upgrade cnDBTier on all sites first and then NSSF on all sites. For example: There are two sites (site 1 and site 2). Both running on release N-1 and cnDBTier is also on N-1. To upgrade NSSF and cnDTier to release N:

Upgrade NSSF at Site 1 to version N. Wait for 10 minutes.
Upgrade NSSF at Site 2 to version N. Wait for 10 minutes.
Upgrade cnDBTier at Site 1 to version N. Wait for 10 minutes.
Upgrade cnDBTier at Site 2 to version 24.1.0. Wait for 10 minutes.

To rollback from N to N-1:

Rollback cnDBTier at Site 1 to version N-1. Wait for 10 minutes.
Rollback cnDBTier at Site 2 to version N-1. Wait for 10 minutes.
Rollback NSSF at Site 1 to version N-1. Wait for 10 minutes.
Rollback NSSF at Site 2 to version N-1. Wait for 10 minutes.

4.2 Upgrade Strategy

NSSF supports in-service upgrade. The supported upgrade 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.

The following read-only-parameters are used to define upgrade strategy:

upgradeStrategy parameter indicates the update strategy used in NSSF.
maxUnavailable parameter determines the maximum number of pods that will be unavailable during upgrade.

Table 4-2 Predefined Upgrade Strategy Value

Microservice	Upgrade Value (maxUnavailable)
<Helm-release-name>-nsselection	25%
<Helm-release-name>-nsavailability	25%
<Helm-release-name>-nssubscription	25%
<Helm-release-name>-nsconfig	25%
<Helm-release-name>-nsauditor	25%
<Helm-release-name>-nrf-client-nfdiscovery	25%
<Helm-release-name>-nrf-client-nfmanagement	25%
<Helm-release-name>-ingressgateway	25%
<Helm-release-name>-egressgateway	25%
<Helm-release-name>-appinfo	25%
<Helm-release-name>-perf-info	25%
<Helm-release-name>-config-server	25%
<Helm-release-name>-alternate-route	25%

Note:

<Helm-release-name> is the Helm release name. For example, if Helm release name is "ocnssf", then nsselection microservice name will be "ocnssf-nsselection"

4.3 Preupgrade Tasks

This section provides information about preupgrade tasks to be performed before upgrading NSSF.

To check the preupgrade health of NSSF, perform a Helm test before starting the upgrade. For more information about Helm test, see Performing Helm Test section.
Keep current custom_values.yaml file as backup.
Update the new custom_values.yaml file for target NSSF release. For details on customizing this file, see Customizing NSSF.
Before starting the upgrade, take a manual backup of NSSF REST based configuration. This helps if preupgrade data has to be restored. For Rest API configuration details, see Oracle Communications Cloud Native Core, Network Slice Selection Function REST Specification Guide.

4.4 Upgrade Tasks

This section provides information about the sequence of tasks to be performed for upgrading an existing NSSF deployment.

Helm Upgrade

Upgrading an existing deployment replaces the running containers and pods with new containers and pods. If there is no change in the pod configuration, it is not replaced. Unless there is a change in the service configuration of a microservice, the service endpoints remain unchanged.

Upgrading NSSF

Caution:

Stop the provisioning traffic before you start the upgrade procedure.
No configuration should be performed during upgrade.
Do not exit from helm upgrade command manually. After running the helm upgrade command, it takes some time (depending upon the number of pods to upgrade) to upgrade all the services. In the meantime, you must not press "ctrl+c" to come out from helm upgrade command. It may lead to anomalous behavior.

Untar the latest NSSF package and if required, re-tag and push the images to registry. For more information, see Downloading the NSSF Package and Pushing the Images to Customer Docker Registry.
Modify the ocnssf_custom_values_24.1.1.yaml file parameters as per site requirement.
Do not change the nfInstanceId configuration for the site. In case of multisite deployments, configure nfInstanceId uniquely for each site.
Assign appropriate values to core_services in the appInfo configuration based on nssf Mode.
Run the following command to upgrade an existing NSSF deployment:

Note:
If you are upgrading an existing NSSF deployment with georedundancy feature enabled, ensure that you configure dbMonitorSvcHost and dbMonitorSvcPort parameters before running helm upgrade. For more information on the parameters, see Global Parameters.
- Using local Helm chart:
```
$ helm upgrade <release_name> <helm_chart> -f <nssf_customized_values.yaml> --namespace <namespace>
```
  Where,
  
  <release_name> is the NSSF release name.
  
  <helm_chart> is the Helm chart.
  
  <nssf_customized_values.yaml> is the latest custom-values.yaml file. For example, ocnssf_custom_values_24.1.1.yaml
  
  <namespace> is namespace of NSSF deployment.
  
  For example:
  $ helm upgrade ocnssf ocnssf-24.1.1.0.0.tgz -f ocnssf_custom_values_24.1.1.yaml --namespace ocnssf
- Using chart from Helm repo:
```
$ helm upgrade <release_name> <helm_repo/helm_chart> --version <chart_version> -f <nssf_customized_values.yaml> --namespace <namespace>
```
  Where,
  
  <release_name> is the NSSF release name.
  
  <helm_repo/helm_chart> is the Helm repository for NSSF.
  
  <nssf_customized_values.yaml> is the latest custom-values.yaml file. For example, ocnssf_custom_values_24.1.1.yaml
  
  <namespace> is namespace of NSSF deployment.
  
  For example:
  $ helm upgrade ocnssf ocnssf-helm-repo/ocnssf--version 24.1.1 -f ocnssf_custom_values_24.1.1.yaml --namespace ocnssf
Run the following command to check the status of the upgrade:
```
$ helm status <release_name> --namespace <namespace>
```
Where,

<release_name> is the NSSF release name.

<namespace> is namespace of NSSF deployment.

For example:
$ helm status ocnssf--namespace ocnssf
If the upgrade fails, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Network Slice Selection Function Troubleshooting Guide.

4.5 Postupgrade Tasks

This section provides information about postupgrade tasks to be performed after upgrading NSSF.

To check the postupgrade health of NSSF, perform a Helm test after the upgrade. For more information about Helm test, see Performing Helm Test section.
After NSSF upgrade, upgrade cnDBTier using the ocnssf_dbtier_24.1.1_custom_values_24.1.1.yaml file provided in the ocnssf-custom-configtemplates-24_1_1_0_0 file. For information about the steps to download ocnssf-custom-configtemplates-24_1_1_0_0 file, see Customizing NSSF.

Note:
There are no customizations required in the ocnssf_dbtier_24.1.1_custom_values_24.1.1.yaml file for installing NSSF 24.1.1.
Run the following command to upgrade your current cnDBTier installation using the ocnssf_dbtier_24.1.1_custom_values_24.1.1.yaml file:
```
helm upgrade <release-name>  <chart-path> -f <cndb-custom-values.yaml> -n <namespace>
```
For example:

helm upgrade mysql-cluster occndbtier/ -f ocnssf_dbtier_24.1.1_custom_values_24.1.1.yaml -n nssf-cndb

For more information about cnDBTier installation and upgrade procedure, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.