Upgrading NSSF

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.3.x	23.4.0

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.
If you are upgrading from NSSF release 23.2.x to 23.3.x or later versions, upgrade the ASM chart first before upgrading the NF. Run the flowing command to upgrade the ASM chart:
```
$ helm upgrade <servicemesh_release_name> <servicemesh_helm_chart> --namespace <namespace> -f <nssf_servicemesh_custom_values.yaml>
```
Where,

<servicemesh_release_name> is the ASM release name.

<servicemesh_helm_chart> is the ASM Helm chart.

<namespace> is namespace of NSSF deployment.

<nssf_servicemesh_custom_values.yaml> is the latest servicemesh custom-values.yaml file. For example, ocnssf_servicemesh_config_custom_values_23.4.0.yaml

For example:
```
helm upgrade ocnssf-servicemesh-config ocnssf-servicemesh-config-23.4.0.0.0.tgz --namespace ocnssf -f ocnssf_servicemesh_config_custom_values_23.4.0.yaml
```
The NRF Client Database (nrf_client_db) was introduced in release 23.3.0. If you are upgrading from version 23.2.x to 23.3.x or later versions, follow the steps mentioned below to manually create the NRF Client Database before upgrading:
1. Run the following command to create a new NRF Client Database:
```
$ CREATE DATABASE IF NOT EXISTS <DB Name> CHARACTER SET latin1;
```
  For example:
  
  $ CREATE DATABASE IF NOT EXISTS nrf_client_db CHARACTER SET latin1;
  Note:
  - Ensure that you use the same database name while creating database that you have used in the global parameters of ocnssf_custom_values_23.4.0.yaml file. Following is an example of name of the NRF Client Database configured in the ocnssf_custom_values_23.4.0.yaml file:
```
nrfClientDbName: nrf_client_db
```
  - For multisite georedudnant setups, change the parameter value of the NRF Client Database name (nrf_client_db) uniquely for each site in the ocnssf_custom_values_23.4.0.yaml file. For example, change the values as mentioned below in case of two-site and three-site setup, respectively:
    For Two-Site:
    
    Change the value of global.nrfClientDbName as nrf_client_db1 and nrf_client_db2 for one-site and two-site scenarios, respectively.
    For Three-Site:
    
    Change the value of global.nrfClientDbName as nrf_client_db1,, nrf_client_db2, and nrf_client_db3 for one-site, two-site, and three-site scenarios, respectively.
2. Run the following command to grant Privileged User permission on NRF Client Database:
```
$ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, REFERENCES, EXECUTE ON <DB Name>.* TO '<NSSF Privileged Username>'@'%';
```
  For example:
  
  $ GRANT SELECT, INSERT, CREATE, ALTER, DROP, LOCK TABLES, CREATE TEMPORARY TABLES, DELETE, UPDATE, REFERENCES, EXECUTE ON nrf_client_db.* TO 'nssfprivilegedusr'@'%';
  
  Note:
  Run this step on all the SQL nodes for each NSSF standalone site in a multisite georedundant setup.
3. Run the following command to flush privileges:
```
FLUSH PRIVILEGES;
```
4. For more information about creating database and granting privileges on single and multisite georedundant setups, see Configuring Database, Creating Users, and Granting Permissions.
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_23.4.0.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_23.4.0.yaml
  
  <namespace> is namespace of NSSF deployment.
  
  For example:
  $ helm upgrade ocnssf ocnssf-23.4.0.0.0.tgz -f ocnssf_custom_values_23.4.0.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_23.4.0.yaml
  
  <namespace> is namespace of NSSF deployment.
  
  For example:
  $ helm upgrade ocnssf ocnssf-helm-repo/ocnssf--version 23.4.0 -f ocnssf_custom_values_23.4.0.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_23.4.0_custom_values_23.4.0.yaml file provided in the ocnssf-custom-configtemplates-23_4_0_0_0 file. For information about the steps to download ocnssf-custom-configtemplates-23_4_0_0_0 file, see Customizing NSSF.

Note:
There are no customizations required in the ocnssf_dbtier_23.4.0_custom_values_23.4.0.yaml file for installing NSSF 23.4.0.
Run the following command to upgrade your current cnDBTier installation using the ocnssf_dbtier_23.4.0_custom_values_23.4.0.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_23.4.0_custom_values_23.4.0.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.

4 Upgrading NSSF

4.1 Supported Upgrade Paths

4.2 Upgrade Strategy

4.3 Preupgrade Tasks

4.4 Upgrade Tasks

4.5 Postupgrade Tasks