4 Upgrading BSF

This chapter provides information about upgrading Oracle Communications Cloud Native Core, Binding Support Function (BSF) deployment to the latest release. It is recommended to perform BSF upgrade in a specific order. For more information about the upgrade order, see Oracle Communications Cloud Native Core, Solution Upgrade Guide.

Note:

  • In a georedundant deployment, perform the steps explained in this section on all the georedundant sites.
  • For BSF georedundant deployments, during a site upgrade the difference between the BSF release versions for all the georedundant sites cannot be more than 1 release.

    For example, In a three-site BSF deployment, all the 3 sites are at the same release version as N. During site upgrade, site 1 and site 2 are upgraded to N+1 version, and site 3 is not upgraded yet. At this State, before upgrading site 3 to N+1, upgrading site 1 and/or site 2 from N+1 version to N+2 version is not supported as the difference between the BSF release versions for all the georedundant sites cannot be more than 1 release.

    For more information about the cnDBTier georedundant deployments, see Oracle Communications Cloud Native Core, cnDBTier Installation, Upgrade, and Fault Recovery Guide.

    For more information about the CNC Console georedundant deployments, see Oracle Communications Cloud Native Core, CNC Console Installation, Upgrade, and Fault Recovery Guide.

4.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for BSF:

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

Note:

BSF must be upgraded before upgrading cnDBTier.

.

4.2 Upgrade Strategy

BSF 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 engineering configuration parameters are used to define upgrade strategy:
  • upgradeStrategy parameter indicates the update strategy used in BSF.
  • maxUnavailable parameter determines the maximum number of pods that can be unavailable during upgrade.

    For more information on maxUnavailable for each microservices refer PodDisruptionBudget Configuration section.

Note:

When BSF is deployed with OCCM, follow the specific upgrade sequence as mentioned in the Oracle Communications, Cloud Native Core Solution Upgrade Guide.

4.3 Preupgrade Tasks

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

  1. Backup the current custom-values.yaml file.
  2. Update the new custom_values.yaml file for target BSF release. For details on customizing this file, see Customizing BSF.
  3. Before starting the upgrade, take a manual backup of BSF REST based configuration. This helps if preupgrade data has to be restored.

    Note:

    For Rest API configuration details, see Oracle Communications Cloud Native Core, Binding Support Function REST Specification Guide.
  4. Before upgrading, perform sanity check using Helm test. See the Performing Helm Test section for the Helm test procedure.
  5. Install or upgrade the network policies, if applicable. For more information, see Configuring Network Policies.

Note:

It is recommended to perform BSF upgrade in a specific order. For more information about the upgrade order, see Oracle Communications Cloud Native Core, Solution Upgrade Guide.

Before starting the procedure to upgrade Binding Support Function (BSF), perform the following tasks:
  • Since Diameter Connector is removed from BSF, perform any of the following methods to prepare system for upgrade with functional Diameter Connector:

    One-step Upgrade: Set the value of diamConnectorEnable as false in the custom values yaml file and then perform the upgrade. This method is a site isolation upgrade and may have an impact on traffic.

    OR

    Two-step Upgrade:
    1. Set the value of the diamConnectorEnable parameter as true in the custom values yaml file and perform the upgrade.
    2. After a successful upgrade, change the value of diamConnectorEnable to false in the same custom values yaml file and rerun the upgrade command.

      Running the same upgrade command twice by changing the diamConnectorEnable parameter values does not impact the traffic.

4.4 Upgrade Tasks

This section includes information about upgrading an existing Binding Support Function (BSF) 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.

Upgrade Procedure

Caution:

  • Stop the provisioning traffic before you start the upgrade procedure.
  • Do not perform any configuration changes during the 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.
  1. Unzip the release package file to the system where you want to deploy BSF. The BSF release package is named using the following convention:

    ReleaseName-pkg-Releasenumber.tgz

    where, ReleaseName is the name used to track a particular installation instance and

    Releasenumber is the release number.

    For BSF 24.3.0, the release package file name is ocbsf-pkg24.3.0.0.0.tgz.

    Note:

    For information on how to download the package from My Oracle Support (MOS), see Downloading BSF package.
  2. Untar the BSF package file to get the docker image tar file:
    tar -xvzf ReleaseName-pkg-ReleaseNumber.tgz

    For Example: 

    tar -xvzf ocbsf-pkg-24.3.0.0.0.tgz
    The directory consists of the following:
    • ocbsf-images-24.3.0.tar - BSF Docker Images File
    • ocbsf-24.3.0.tgz - Helm Charts
    • Readme.txt - Readme txt file
    • ocbsf-24.3.0.tgz.sha256 - Checksum for Helm chart tgz file
    • ocbsf-images-24.3.0.tar.sha256 - Checksum for images tgz file
  3. Load and Push the Images to Customer Docker Registry. See Pushing the Images to Customer Docker Registry.
  4. Modify the required custom-values.yaml file for the target BSF release. To learn how to customize the file or any specific parameters, see Customizing BSF.

    Note:

    The values of the parameters mentioned in the custom values yaml file overrides the defaults values specified in the helm chart. If the envMysqlDatabase parameter is modified, then you should modify the configDbName parameter with the same value.

  5. Upgrade BSF using Helm:

    helm upgrade <release-name> <helm-chart> -f <custom-file> -n <release-namespace>

    Example:

    helm upgrade ocbsf ocbsf-24.3.0.tgz -f ocbsf-24.3.0-custom-values.yaml -n ocbsf
    where:

    helm_chart is the location of the helm chart extracted from ocbsf-24.3.0.tgz file

    release_name is the release name used by helm command.

    release_namespace is the deployment namespace used by helm command.

    custom_file - is the name of the custom values yaml file.

    Optional parameters that can be used in the helm install command:
    • atomic:If this parameter is set, installation process purges chart on failure. The --wait flag will be set automatically.
    • wait: If this parameter is set, installation process will wait until all pods, PVCs, Services, and minimum number of pods of a deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout.
    • timout duration: If not specified, default value will be 300 (300 seconds) in Helm. It specifies the time to wait for any individual Kubernetes operation (like Jobs for hooks). If the helm install command fails at any point to create a Kubernetes object, it will internally call the purge to delete after the timeout value. Here, the timeout value is not for overall installation, but for automatic purge on installation failure.

    Note:

    It is recommended not to use --wait and --atomic parameters along with helm upgrade as this might result in upgrade failure.

    Note:

    The following warnings must be ignored for BSF upgrade on 24.3.0, 24.2.0 and 24.1.0 CNE:
    helm install <release-name> -f <custom.yaml> <tgz-file> -n <namespace>
W0301 07:39:30.096125 1718193 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[1]
W0301 07:39:34.033420 1718193 warnings.go:70] spec.template.spec.containers[0].ports[3]: duplicate port definition with spec.template.spec.containers[0].ports[2]
Release "<release-name>" has been upgraded. Happy Helming!
NAME: <release-name>
LAST DEPLOYED: <Date-Time>
NAMESPACE: <namespace>
STATUS: deployed
REVISION: <N>
  6. Run the following command to check the status of jobs and pods:
    kubectl get jobs,pods -n release_namespace
    For example: 
    kubectl get jobs,pods -n ocbsf
    You should see the status as Running for all the pods if BSF is deployed successfully.
  7. Before upgrading, perform sanity check using Helm test. See the Performing Helm Test section for the Helm test procedure.
  8. If the upgrade for BSF fails due to any of the following conflicts, you are required to delete the conflicting items using the relevant commands as follows:
    • In case of conflict due to rolebinding, run the following command:
      kubectl delete rolebinding <conflicting item> -n <namespace>
    • In case of conflict due to PodDisruptionBudget, run the following command:
      kubectl delete PodDisruptionBudget <conflicting item> -n <namespace>

    If the upgrade fails due to any other reason, see Upgrade or Rollback Failure in Oracle Communications Cloud Native Core, Binding Support Function Troubleshooting Guide.

Note:

To automate the lifecycle management of the certificates through OCCM, you can migrate certificates and keys from BSF to OCCM. For more information, see "Introducing OCCM in an Existing NF Deployment" in Oracle Communications Cloud Native Core, Certificate Management User Guide.

You can remove Kubernetes secrets if the current version of BSF does not use that secret by checking the ocbsf_custom_values.yaml file. Before deleting, please make sure that there is no plan to rollback to the BSF version which uses these secrets. Otherwise Rollback will fail.

4.5 MIB Management

toplevel.mib and BSF-ALARM-MIB.mib are two MIB files which are used to generate the traps. You must update these files along with the Alert file in order to fetch the traps in their environment. The MIB files are managed by SNMP manager.

Note:

bsf_alarm_mib.mib file has been replaced by BSF-ALARM-MIB.mib file.