Upgrading SCP

4 Upgrading SCP

You can upgrade SCP from a source release to a target release using procedures outlined in this chapter.

4.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for SCP:

Table 4-1 SCP Supported Upgrade Paths

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

Note:

The upgrade of an IPv6 setup with a source release of 23.x.y is not supported for upgrading to 24.x.y.
SCP must be upgraded before upgrading cnDBTier.

4.2 Upgrade Strategy

SCP 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 configuration parameters define the upgrade strategy:

The upgradeStrategy parameter indicates the update strategy in SCP.
The maxUnavailable parameter determines the number of pods that are unavailable during the update.
The maxSurge parameter determines the number of pods that can be created above the desired amount of pods during an upgrade.

Table 4-2 Predefined Upgrade Strategy Value

Microservice	Upgrade Value (maxUnavailable)	Upgrade Value (maxSurge)
scp-worker	25%	25%
scp-nrfproxy	25%	25%
scp-mediation	25%	25%

4.3 Preupgrade Tasks

Perform the following procedure before upgrading SCP.

Note:

The releaseVersion value in the ocscp_values.yaml file can not be changed.
While performing an upgrade from an older release to a newer release, you must align the ocscp_values.yaml file of the new release as per the ocscp_values.yaml file of the older release. Ensure that you do not change any Helm parameter values. During the upgrade, modifications are allowed for the following parameters: scpProfileInfo.plmnList, scpProfileInfo.customInfo.mateScpInfoList, scpProfileInfo.customInfo.mateSiteInfo, and TLS configuration. Other parameters should not be modified during the upgrade process. Do not enable any new feature during the upgrade. Any ocscp_values.yaml parameter must not be changed while upgrading unless explicitly specified in this guide. For information about enabling any new feature through Helm parameters, see Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.
Install or upgrade the network policies, if applicable. For more information, see Configuring Network Policies for SCP
Ensure that the Service Account, Role, and Rolebinding are as per the current release. For more information, see Creating Service Account, Role, and Rolebinding.

Download the SCP package from My Oracle Support (MOS) as described in Downloading the SCP Package.
Push the images to Customer Docker Registry as described in Pushing the Images to Customer Docker Registry.
Keep the ocscp_values.yaml file of the source release (24.2.x and 24.1.x) as backup while upgrading from the source release to 24.3.0.
Update the ocscp_values.yaml (24.3.0) file as per the target release as described in Customizing SCP.
While upgrading from 24.2.x and 24.1.x to 24.3.0, do the following:
- To configure multiple TLS certificates for ingress and egress connections, update the values of the following Helm parameters in server and client subsections of the sbiProxySslConfigurations parameter in the 24.3.0 ocscp_values.yaml file with the same values available for the sslConfigurations parameter in the 24.2.x or 24.1.x ocscp_values.yaml file:
  - primary.secretName
  - primary.privateKey
  - primary.certificate
  - primary.caBundle
  - primary.keyStorePassword
  - primary.trustStorePassword
- To configure Oracle Communications Network Analytics Data Director (OCNADD) connection, update the values of the following Helm parameters in the ddSslConfiguration section in the 24.3.0 ocscp_values.yaml file with the same values available for the ddSslConfiguration parameter in the 24.2.x and 24.1.x ocscp_values.yaml file:
  - primary.k8SecretName
  - primary.trustStorePassword
  - primary.caBundle
  - primary.trustStoreType
  - primary.certificate
  - primary.privateKey
  - primary.keyStorePassword
  - primary.keyStoreType
Ensure that the coherence.clusterName parameter value is the same as the previous releases.
You must edit the coherence.clusterName parameter value to be equivalent with the ${RELEASE_NAME}-${COHERENCE_CLUSTER_NAME}-${POD_NAMESPACE} format, which was used in the previous releases. To edit the coherence.clusterName parameter value, prefix the SCP release name with a hyphen (-), and then suffix with a hyphen (-) and the namespace. A sample coherence.clusterName is as follows: ocscp-scp-coherence-cluster-scpsvc, where ocscp is the SCP release name and scpsvc is the namespace.
In case of a fresh installation, this parameter value can be set to any required value with a maximum of 66 characters.
Ensure that the minimum resource requirements are achieved for SCP upgrade as described in Upgrade.
Delete all the older versions backup tables from the backup DB except the ReleaseConfig table.
For example, if the current SCP deployed version is 24.3.0 (numeric value 2400300), then all the tables with the string 'backup' and a version field less than 2400300 can be deleted.

Sample backup table name: TRAFFIC_FEED_DATA_DIRECTOR_CONFIG_backup_2200200. Here, the version value is 2200200. In this example, the given table can be deleted before upgrading.
Perform sanity check using Helm test as described in Performing Helm Test.

4.4 Upgrade Tasks

Perform this procedure to upgrade SCP.

Note:

SCP might raise alerts while performing an upgrade. To clear any alert, see "Alerts" in Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.
SCP uses the upgraderollbackevents resource to retrieve the list of upgrade and rollback events. For more information, see Oracle Communications Cloud Native Core, Service Communication Proxy REST Specification Guide.

Ensure that no SCP pod is in the failed state.
Complete the tasks as described in Preupgrade Tasks.

Caution:

No configuration should be performed during upgrade.

Note:

If there are less than or equal to 32 SCP-worker pods, the timeout value during the Helm upgrade must be set to 30 minutes.
If there are more than 32 SCP-worker pods, the timeout value during the Helm upgrade must be changed to 60 minutes.

Helm Upgrade

Upgrading an existing deployment replaces the running containers and pods with target release containers and pods. If there is no change in the pod configuration, then 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 an existing SCP deployment, run the following command:
1. Using the local Helm chart:
```
helm upgrade <release_name> <helm_chart> -f <ocscp_values.yaml>--namespace <namespace-name> --timeout=30m
```
  Where,
  - <release_name> is the release name used by the Helm command.
  - <helm_chart> is the location of the Helm chart extracted from the target file.
  - <ocscp_values.yaml> is the SCP customized values.yaml for target release.
  - <namespace-name> is the SCP namespace in which release is deployed.
  Example:
```
helm upgrade ocscp  -f ocscp_values_24.3.0.yaml --namespace ocscp --timeout=30m
```
2. Using chart from Helm repo:
```
helm upgrade <release_name> <helm_repo/helm_chart> --version <chart_version> -f <ocscp_values.yaml> --namespace <namespace-name> --timeout=30m
```
  Where,
  - <helm_repo> is the SCP Helm repo.
  - <chart_version> is the version of the Helm chart extracted from the file.
  Example:
```
helm upgrade ocscp ocscp-helm-repo/ocscp --version -f ocscp_values_24.3.0.yaml --namespace ocscp --timeout=30m
```
Caution:
Do not exit from the Helm upgrade command manually. After running the Helm upgrade command, wait until all of the services are upgraded. Do not press "ctrl+c" to come out from the Helm upgrade command. It may lead to uncommon behavior.

To check the status of the upgrade, run the following command:

helm history <release_name> --namespace <namespace-name>

Note:

After upgrading to SCP 24.3.0, the <release_name>-scp-worker-headless service is present with no active pods. It is removed in 24.3.0.

Sample output of a successful upgrade

REVISION        UPDATED                         STATUS          CHART          APP VERSION     DESCRIPTION
1               Tue September 03 06:55:48 2024        superseded      ocscp_24.3.0   24.3.0.0.0      Install complete
2               Tue September 03 07:08:08 2024        deployed      ocscp_24.3.0   24.3.0.0.0      Upgrade complete

If the upgrade fails, see Oracle Communications Cloud Native Core, Service Communication Proxy Troubleshooting Guide.

Note:
You must clean up any residual job from the SCP deployment after the upgrade is complete.
Perform sanity check using Helm test as described in Performing Helm Test.

4.5 Postupgrade Tasks

Note:

To upgrade cnDBTier with resources recommended for SCP, customize the ocscp_dbtier_24.3.0_custom_values_24.3.0.yaml file in the ocscp_csar_24_3_0_0_0.zip folder with the required deployment parameters. cnDBTier parameters will vary depending on whether the deployment is on a single site, two site, or three site. For more information, see cnDBTier Customization Parameters.
For more information about cnDBTier upgrade, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
To automate the lifecycle management of the certificates through OCCM, you can migrate the lifecycle of certificates and key management from manual to OCCM. For more information, see "Introducing OCCM in an Existing NF Deployment" section in Oracle Communications Cloud Native Core, Certificate Management User Guide.

Note:
SCP application does not manage the LCM of the certificate and key.