Upgrading UDR

4.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for UDR:

Table 4-1 Supported Upgrade Paths

Source Release	Target Release
24.2.x	24.3.0
24.1.x	24.3.0

4.2 Preupgrade Tasks

This section provides information about preupgrade tasks to be performed before upgrading UDR:

Take a backup of the current custom-values.yaml file.
Update the new custom_values.yaml file. For more details about Helm configurable parameters, see UDR Configuration Parameters.
Provisioning traffic must be stopped when the upgrade procedure is performed.
Make sure that the current deployment is good for an upgrade before you perform an upgrade on the existing deployment. To verify the current deployment, see Verifying Installation.
Before upgrading, perform sanity check using Helm test. See Performing Helm Test section for the Helm test procedure.
Install or upgrade the network policies, if applicable. For more information, see Configuring Network Policies.

4.3 Upgrade Task

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

Helm Upgrade

To upgrade UDR 24.2.x to 24.3.0, follow the instructions given below.

Note:

During in service upgrade from 24.2.x to 24.3.0, there can be a traffic loss of about 1%.

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. For example, ClusterIP.

To upgrade multiple site deployment, see Upgrade of Multiple Site Deployments.

Configuring cnDBTier

The following step is applicable only for multiple site cnDBTier deployment.
Update mysqld configuration in the cnDBTier custom values file before the installing or upgrading UDR or SLF.
```
global:
  ndbconfigurations:
    api
      auto_increment_increment: 3
      auto_increment_offset: 1
```
Note:
- Set the auto_increment_increment parameter as same as number of sites. For example: If the number of sites is 2, set its value as 2 and if the number of sites is 3, set its value as 3.
- Set the auto_increment_offset parameter as site ID. For example: The site ID for Site 1 is 1, Site 2 is 2, for Site 3 is 3 and so on.
- If the fresh installation or upgrade of UDR or SLF on cnDBTier is not planned, then run the following command to edit the exiting mysqldconfig configmap on all the cnDBTier sites.
```
kubectl edit configmap mysqldconfig <db-site-namespace>
```
  For Example: kubectl edit configmap mysqldconfig -n site1
  
  Note:
  Update the auto_increment_increment and auto_increment_offset values as mentioned in the previous step for all sites.
The following changes are made in the cnDBTier custom values shared as part of UDR custom templates:
- The value of HeartbeatIntervalDbDb parameter is changed in the cnDBTier custom values files. Before performing Helm upgrade of cnDBTier, you must refer to Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide for upgrade instructions to perform the configuration changes.
- The disk size is updated and SLF and EIR resource profiles are changed due to the subscriber base increase. You must refer to Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide to perform the configuration changes.

Upgrading UDR

Caution:

Stop the provisioning traffic before you start the upgrade procedure.
Do not configure UDR while the upgrade is in progress.
Do not exit the helm upgrade command manually. After running the helm upgrade command, it takes sometime (depending upon number of pods to upgrade) to upgrade all of the services. Do not press "ctrl+c" to exit the helm upgrade command. It may lead to anomalous behavior.

Untar the latest OCUDR software components and if required, re-tag and push the images to customer's repository. For more information about extracting OCUDR software components, see Pushing the Images to Customer Docker Registry.
Take a backup of the 24.2.x version's <ocudr-values.yaml> file.
Modify the ocudr-custom-values-24.3.0 yaml file parameters as per site requirement.
Retain the nfInstanceId configuration for the site same as OCUDR 24.1.x values. In case of multisite deployments, configure nfInstanceId differently for each SLF or UDR.
Ensure the nfInstanceId configuration in the global section is same as that in the appProfile section of NRF client.

Note:
This step is applicable to all UDR installations from 1.14.x onwards.
The following steps are required only when the Control Shutdown feature need to be enabled or it is enabled during upgrade:
- Perform the following steps when Control Shutdown feature is enabled and upgraded from 23.2.x to 24.3.0:
  1. Log into one of the cnDBtier pods using the exec command.
    Example:
```
kubectl exec -it <pod-name> -n <namespace> bash
```
  2. Run the following command to choose the database:
```
use configDB
```
  3. Run the following command to update the supported configuration item for operational state:
```
UPDATE configuration_item SET cfg_value='{"operationalState":"NORMAL","operationalStateHistory":[]}' where cfg_key='OPERATIONAL-STATUS';
```
The following steps are required only when the Network Policy and Conflict Resolution features need to be enabled during upgrade:
- Enable Network Policy when upgrading to 24.3.0, see Configuring Network Policies and Network Policy section in the Oracle Communications Cloud Native Core, Unified Data Repository User Guide.
- Enable Conflict Resolution when upgrading to 24.3.0, see Conflict Resolution section in the Oracle Communications Cloud Native Core, Unified Data Repository User Guide.
Assign appropriate values to core_service in the appInfo configuration based on udrMode.

Note:
This step is applicable to all UDR installations from 1.14.x onwards.
Change the configurations in the ocudr-custom-values-24.3.0.yaml file as per site requirements. For more information about UDR configuration, see UDR Configuration Parameters.
Run the following command to upgrade an existing UDR deployment.
```
$ helm upgrade <release> <helm chart> [--version <OCUDR version>] -f <ocudr-custom-values-24.3.0.yaml>
 
```
<release> is available in the output of helm list command.

<helm chart> is the name of the chart in the form of <repository/ocudr> e.g. reg-1/ocudr or cne-repo/ocudr.
```
$ helm upgrade <release> -n <namespace> <helm chart> [--version <OCUDR version>] -f <ocudr-custom-values-24.3.0.yaml>
 
```
<release> is available in the output of helm list command.

<helm chart> is the name of the chart in the form of <repository/ocudr> e.g. reg-1/ocudr or cne-repo/ocudr.
Perform sanity check using Helm test. See Performing Helm Test section for the Helm test procedure.

The below steps are applicable only when there is a helm upgrade failure:

If the helm upgrade failure is intermittent, check the below error scenarios.
1. If the helm upgrade fails with <helm-release-name>-nudr-config-server-pre-rollback/<helm-release-name>-nudr-config-server-post-rollback hook running into Error state, check the logs of the failed hook.
2. Perform Step 3, if the logs show any of the following errors:
  1. "message":"Unknown column 'tb.snapshot_id' in 'where clause'"
  2. "message":"Rolling back to the savepoint and exiting...","thrown":{"commonElementCount":0,"localizedMessage":"Table 'udrconfigdb.snapshot_mapping' doesn't exist","message":"Table udrconfigdb.snapshot_mapping' doesn't exist"
3. Update the database tables using the following workaround SQL statements:
  1. Run the following command to log in to ndbappsql node pods.
```
"kubectl exec <sqlnode> -n <ns> -it bash"
```
  2. Copy the below command in codeblock to a commands.sql file. The commands.sql file can be created using vim editor that is present inside mysql pod.
    SQL Commands
```
SET default_storage_engine=NDBCLUSTER;
use udrconfigdb;
drop table if exists snapshot_mapping;
CREATE TABLE IF NOT EXISTS  snapshot_mapping
            ( snapshot_id bigint(20) NOT NULL AUTO_INCREMENT, 
              `name` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
              `created_time` datetime DEFAULT CURRENT_TIMESTAMP,
             `restored_time` datetime DEFAULT NULL,
              PRIMARY KEY (`snapshot_id`), 
              UNIQUE KEY `name` (`name`) )  
              AUTO_INCREMENT=21 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
alter table topic_info_backup add column snapshot_id bigint;
alter table topic_info_backup add foreign key (snapshot_id) references snapshot_mapping(snapshot_id);
alter table configuration_item_backup add column snapshot_id bigint;
alter table configuration_item_backup add foreign key (snapshot_id) references snapshot_mapping(snapshot_id);
use udrdb;
delete from ReleaseConfig where SiteId="5a7bd676-ceeb-44bb-95e0-f6a55a328b03" and CfgKey="nrf-client-nfmanagement";
```
    Note:
    - The second SQL command use udrconfigdb mentioned above must refer to the configuration database name of UDR or SLF
    - The second last SQL command use udrdb mentioned above must refer to the subscriber database name of UDR or SLF.
    - The last SQL command SiteId mentioned above must be same as the one configured in global.nfInstanceId in the ocudr 24.3.0 custom-values.yaml file.
  3. Run the below command to load the SQL commands to the database.
```
mysql -h127.0.0.1 -u<username> -p<password> < commands.sql
```
After performing the above workaround, retry the rollback again using the helm upgrade command.

Upgrade of Multiple Site Deployments

You must follow a specific order during upgrade of multiple site deployment. You must upgrade one site at a time starting with the NF and then cnDBTier. For example, in a three site setup, you must follow the below order for NF and cnDBTier upgrade:

Upgrade Site 1 UDR, Provisioning Gateway, CNC Console, and Tools (subscriber bulk import and subscriber export tool) deployments if present.
Upgrade Site 1 cnDBTier
Upgrade Site 2 UDR, Provisioning Gateway, CNC Console, and Tools (subscriber bulk import and subscriber export tool) deployments if present.
Upgrade Site 2 cnDBTier
Upgrade Site 3 UDR, Provisioning Gateway, CNC Console, and Tools (subscriber bulk import and subscriber export tool) deployments if present.
Upgrade Site 3 cnDBTier

The above upgrade order is required because of the SQL rollback limitation applicable for cnDBTier:

If there are schema changes on any of the tables when running on the higher n+1 release version of cnDBTier, then when you rollback the NF to "n" version of cnDBtier, the schema changes which happened on the higher n+1 version will not be handled and the tables with these changes are dropped and are not re-created on the lower version. For more information, see the Prerequisites section in the Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
Rollback of cnDBTier must be performed carefully as per the specified order mentioned in Rollback of Multiple Site Deployments because UDR, Provisioning Gateway, and Tools (subscriber bulk import and subscriber export tool) upgrade and rollback procedure includes database schema changes.
There must not be database schema change in the current cnDBTier version to rollback. If there is any database schema change after cnDBtier is upgraded, then these schema changes must be reverted. You must contact My Oracle Support for assistance.

Note:

To enable conflict resolution feature during upgrade. For more information, see "Conflict Resolution" section in Oracle Communications Cloud Native Core, Unified Data Repository User Guide. You must perform the schema changes before upgrading UDR components and cnDBTier.
During the upgrade procedure if there is an issue on UDR, Provisioning Gateway, or Tools in any sites, then UDR, Provisioning Gateway, or Tools must be rolled back immediately. Do not rollback cnDBTier. cnDBTier must be rolled back only if there is a cnDBTier upgrade issues.
Verify the cnDBTier after the upgrade is complete. If there are issues, rollback the cnDBTier immediately. Do not rollback UDR, Provisioning Gateway, or Tools, they can remain on the higher version and are compatible with n-1 cnDBTier release.
To avoid failures during cnDBTier rollback due to schema changes (for example, helm upgrade, rollback performed on UDR, Provisioning Gateway, and subscriber bulk import and subscriber export tool deployments), you can drop the modified schema tables manually before rollback and re-create the modified schema tables after the rollback is complete. For more information, see the Prerequisites section in the Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide and contact My Oracle Support for assistance.

If the Provisioning Gateway, nudr-bulk-import, and nudr-export-tool are deployed in the site, the upgrade must be preformed in the order as follows:

Upgrade UDR
Upgrade Provisioning Gateway
Upgrade nudr-bulk-import
Upgrade nudr-export-tool
Upgrade cnDBTier

If the upgrade fails, see the Debugging Upgrade or Rollback Failure section in the Oracle Communications Cloud Native Core, Unified Data Repository Troubleshooting Guide.

4.4 Postupgrade Tasks

Perform the following steps if your upgrading from 24.1.x to 24.3.0 release.

Note:

These steps are not applicable if your upgrading from 24.2.x to 24.3.0 release.

From 24.1.0 release onwards the following features are supported using REST API. The features are migrated from HELM to REST API mode during upgrade procedure. After upgrading from 24.1.x to 24.3.0 release version the following features are disabled by default:

Server Header Support on IGW-Sig
User Agent Header Support on IGW-Sig
User Agent Header Support on EGW

Perform the following steps post the Helm upgrade to configure the following features:

Server Header Support on IGW-Sig:

Perform a GET operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/igw-sig/serverheaderdetails to get the current configurations of the feature.
```
{
    "enabled": false,
    "errorCodeSeriesId": "E1",
    "configuration": {
        "nfType": "",
        "nfInstanceId": "5a7bd676-ceeb-44bb-95e0-f6a55a328b03"
    }
}
```
Perform a PUT operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/igw-sig/serverheaderdetails to enable the feature by setting the enabled parameter to true and configuring the nfType and errorCodeSeriesId as required.
```
{
    "enabled": true,
    "errorCodeSeriesId": "E1",
    "configuration": {
        "nfType": "UDR",
        "nfInstanceId": "5a7bd676-ceeb-44bb-95e0-f6a55a328b03"
    }
}
```

Perform a PUT operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/igw-sig/errorcodeserieslist to configure the error code series list.

[ 
    {
        "id": "P1",
        "exceptionList": [
            "RequestTimeout",
            "ConnectionTimeout",
            "UnknownHostException",
            "NotFoundException"
  
        ],
        "errorCodeSeries":
        [
            {
                "errorSet": "5xx",
                "errorCodes": [503]
            }
        ]
    },
    {
        "id": "E1",
        "errorCodeSeries": [
            {
                "errorSet": "4xx",
                "errorCodes": [
                    -1
                ]
            },
            {
                "errorSet": "5xx",
                "errorCodes": [
                    -1
                ]
            }
        ]
    }
]

User Agent Support on IGW-Sig:
- Perform a GET operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/igw-sig/useragentheadervalidation to get the current configurations of the feature.
```
{
    "enabled": false,
    "validationType": "strict",
    "consumerNfTypes": [
        "PCF",
        "NRF",
        "UDM"
    ]
}
```
- Perform a PUT operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/igw-sig/useragentheadervalidation to enable the feature by setting the enabled parameter to true.
```
{
    "enabled": true,
    "validationType": "strict",
    "consumerNfTypes": [
        "PCF",
        "NRF",
        "UDM"
    ]
}
```
User Agent Support on EGW:
- Perform a GET operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/egw/useragentheader to get the current configurations of the feature.
```
{
    "nfFqdn": "",
    "nfType": "",
    "enabled": false,
    "nfInstanceId": "",
    "addFqdnToHeader": false,
    "overwriteHeader": false
}
```
- Perform a PUT operation on http://<nudr_config_svc_IP>:<port>/udr/nf-common-component/v1/egw/useragentheader to enable the feature by setting the enabled parameter to true and configuring the mandatory. nfType parameter as required.
```
{
    "nfFqdn": "",
    "nfType": "UDR",
    "enabled": true,
    "nfInstanceId": "",
    "addFqdnToHeader": false,
    "overwriteHeader": false
}
```

For more information about REST API, see Oracle Communications Cloud Native Core, Unified Data Repository REST Specification Guide.

4 Upgrading UDR

4.1 Supported Upgrade Paths

4.2 Preupgrade Tasks

4.3 Upgrade Task

4.4 Postupgrade Tasks