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
25.1.2xx	25.2.201
25.2.1xx	25.2.201

Note:

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 Manually 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 (25.2.1xx and 25.1.2xx) as backup while upgrading from the source release to 25.2.201.
Update the ocscp_values.yaml (25.2.201) file as per the target release as described in Customizing SCP.
Before upgrading cnDBTier, for any change related to cnDBTier disk size, PVC size, or resources from source release to target release, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
Update MaxNoOfAttributes, MaxNoOfOrderedIndexes, MaxNoOfTables, and MaxNoOfUniqueHashIndexes parameters before upgrading cnDBTier. For more information about these parameters, see cnDBTier Customization Parameters.
While upgrading from 25.2.1xx or 25.1.2xx to 25.2.201, 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 25.2.201 ocscp_values.yaml file with the same values available for the sslConfigurations parameter in the 25.2.1xx or 25.1.2xx 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 25.2.201 ocscp_values.yaml file with the same values available for the ddSslConfiguration parameter in the 25.2.1xx and 25.1.2xx 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.
While performing the upgrade, you may observe some deviation in SCP traffic processing rate for some of the data plane services, such as SCP-Worker, SCP-nrfProxy, SCP-Mediation, and so on, on Grafana as the pods are scaling down and scaling up. To verify whether there is any actual traffic deviation, it is recommended to check the traffic rate for the same time duration at the consumer NF's side.
The SCP-Load-Manager and SCP-Cache pods running on the target release will re-spin as part of the postupgrade hooks.

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_25.2.201.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_25.2.201.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 25.2.201, the <release_name>-scp-worker-headless service is present with no active pods. It is removed in 25.2.201.

Sample output of a successful upgrade

REVISION        UPDATED                         STATUS          CHART          APP VERSION     DESCRIPTION
1               Mon December 08 06:55:48 2025        superseded      ocscp_25.2.201   25.2.201.0.0      Install complete
2               Mon December 08 07:08:08 2025        deployed      ocscp_25.2.201   25.2.201.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_25.2.201_custom_values_25.2.201.yaml file in the ocscp_csar_25_2_2_0_1_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. SCP application does not manage the LCM of the certificate and key.

4.5.1 Alert Configuration

This section describes how to modify or update SCP alerts as required, based on requirements, after performing the upgrade.

For more information, see the following sections:

4.6 Migrating SCP to Support an ASM Disabled cnDBTier

Perform the following procedure to migrate SCP to an ASM-disabled cnDBTier.

Prerequisites

Ensure that SCP is deployed with ASM enabled.
cnDBTier is deployed with istioSidecarInject.mode parameter set to All.

Upgrade cnDBTier with the istioSidecarInject.mode parameter set to All as described in Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.
Upgrade SCP as described in Upgrade Tasks.
Upgrade the CNC Console as described in Oracle Communications Cloud Native Configuration Console Installation, Upgrade, and Fault Recovery Guide .

Note:
In-service upgrade is not supported for migrating from an ASM-enabled cnDBTier configuration to one that removes ASM from internal communication while retaining ASM only for external communication. You must first divert traffic to another site, then isolate the current site from georeplication before making any change.
Migrate cnDBTier deployment to one with the istioSidecarInject.mode parameter set to external.
This deployment should have sidecar injected only in the pods used for external communication after migration. For more information about the migration procedure, see Oracle Communications Cloud Native Core, cnDBTier User Guide.
Verify if the SCPMicroServiceUnreachable alert is raised.
For more information about the SCPMicroServiceUnreachable alert, see Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.

Ensure that the DestinationRule is present in the ocscp_servicemesh_config_values_25.2.201.yaml file:

DestinationRule for mysql-connectivity-service:

- host: <db-service-name>.<db-namespace>.svc.<domain>   
    exportTo:
      - "."                            # refers to the current namespace
    mode: DISABLE
    name: scp-db-service-dr
    namespace: <scp-namespace>         # change the namespace according to deployment
    sbitimers: true
    tcpConnectTimeout: "750ms"
    tcpKeepAliveProbes: 3
    tcpKeepAliveTime: "1500ms"
    tcpKeepAliveInterval: "1s"

DestinationRule for mysql-cluster-db-monitor-svc

- host: <db-service-name>.<db-namespace>.svc.<domain>   
    exportTo:
      - "."                            # refers to the current namespace
    mode: DISABLE
    name: cncc-db-monitor-dr
    namespace: <cncc-namespace>         # change the namespace according to deployment

Run the following command to upgrade ocscp-servicemesh-config with DestinationRule scp-db-service-dr, where TLS communication to mysql-connectivity-service is set to DISABLE and DestinationRule cncc-db-monitor-dr, where TLS communication to mysql-cluster-db-monitor-svc is set to DISABLE:
```
helm upgrade ocscp-servicemesh-config -f values.yaml charts.tgz -n <scp-namespace> --timeout=30m
```
Ensure that the SCPMicroServiceUnreachable alert is cleared.
For more information about the SCPMicroServiceUnreachable alert, see Oracle Communications Cloud Native Core, Service Communication Proxy User Guide.

Verify the connection between SCP microservices and cnDBTier to ensure that all SCP pods are up and running after the migration.

Sample migration output:

cicdocscp-scp-cache-5f4f7f8476-ffsbp                     2/2   Running   0           15h
cicdocscp-scp-load-manager-5d6f776f5d-rjhkp              2/2   Running   0           15h
cicdocscp-scp-mediation-844d4f9c47-94ksm                 2/2   Running   0           15h
cicdocscp-scp-nrfproxy-6cfcb66b49-kcvdm                  2/2   Running   0           15h
cicdocscp-scp-nrfproxy-oauth-74844b8f85-928st            2/2   Running   0           15h
cicdocscp-scp-worker-557c6bf4fc-z4s7s                    2/2   Running   1           15h
cicdocscp-scpc-alternate-resolution-8845f5d98-k7q9l      2/2   Running   0           15h
cicdocscp-scpc-audit-7b856c5bd5-dlc78                    2/2   Running   0           15h
cicdocscp-scpc-configuration-774845fb49-6qn88            2/2   Running   0           15h
cicdocscp-scpc-notification-5d68d7d998-9xbhl             2/2   Running   0           9h
cicdocscp-scpc-subscription-6d446749ff-v84gf             2/2   Running   0           15h
cncc-acore-ingress-gateway-7545797b4f-w488t              2/2   Running   0           46m
cncc-iam-ingress-gateway-8449f57d48-xd8gw                2/2   Running   0           46m
cncc-iam-kc-0                                            3/3   Running   0           46m
cncc-mcore-cmservice-6786679cc4-9v54w                    2/2   Running   0           46m
cncc-mcore-ingress-gateway-546fb4f79c-6dv62              2/2   Running   0           40m
mysql-cluster-db-backup-manager-svc-6cc6fc5fc7-287wq     1/1   Running   0           11m
mysql-cluster-db-monitor-svc-d47766d56-rz956             1/1   Running   0           12m
ndbappmysqld-0                                           3/3   Running   0           12m
ndbappmysqld-1                                           3/3   Running   0           12m
ndbmgmd-0                                                2/2   Running   0           13m
ndbmgmd-1                                                2/2   Running   0           13m
ndbmtd-0                                                 3/3   Running   0           13m
ndbmtd-1                                                 3/3   Running   0           13m
ndbmtd-2                                                 3/3   Running   0           13m
ndbmtd-3                                                 3/3   Running   0           13m
ndbmysqld-0                                              4/4   Running   0           12m
ndbmysqld-1                                              4/4   Running   0           12m
ndbmysqld-2                                              4/4   Running   0           12m
ndbmysqld-3                                              4/4   Running   0           12m

Run the following command to perform Helm test to check the state of the deployments:
```
helm test ocscp -n  <scp-namespace> --logs
```
No error logs should be present in the output of this command.
Divert the traffic back to this SCP site.