Upgrading OSO

5 Upgrading OSO

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

Note:

While performing OSO upgrade from 25.1.2xx or 25.2.1xx to 25.2.200, a small service interruption is expected. This outage is caused because OSO pods will be deleted and recreated after the upgrade.
When performing an OSO upgrade, if you make changes to the configmap, the OSO pods do not restart automatically and continue using the existing data.To ensure the OSO pods retrieve the latest data, add the following to the ocoso_csar_25_2_200_0_0_0_alm_custom_values.yaml file:
```
configmapReload:
	extraArgs:
    	webhook-url: http://127.0.0.1:9093/<CLUSTER-NAME>/alertmanager/-/reload
```
Where, <CLUSTER-NAME> is the name of the target cluster where OSO is deployed.
For more details about the AlertManager configuration parameters, see Alertmanager Configuration Parameters.

5.1 Supported Upgrade Paths

The following table lists the supported upgrade paths for OSO:

Table 5-1 Supported Upgrade Paths

Source Release	Target Release
25.2.1xx	25.2.200
25.1.2xx	25.2.200

5.2 Prerequisites

Following are the prerequisites for upgrading OSO:

Ensure that the system has OSO 25.2.1xx or 25.1.2xx installed and the OSO is working properly.
Verify if all the pods and services are up and running.
Ensure that the NFs are upgraded after the OSO upgrade.

5.3 Upgrading OSO using CSAR

This section describes the procedure to upgrade an existing OSO using CSAR.

Prepare the ocoso_csar_25_2_200_0_0_0_custom_values.yaml file by performing the following steps. This .yaml file is used as the input during the upgrade process.
1. Download OSO CSAR zip file from My Oracle Support (MOS).
2. Unzip the CSAR zip file:
```
$ unzip <OSO CSAR package>
```
3. Upload all the artifacts present in the Artifacts/Images folder to the configured repository. For more information on the artifacts, see the Installation Prerequisite section.
4. Update the Prometheus and Alertmanager ocoso_csar_prom_25_2_200_0_0_0_custom_values.yaml and ocoso_csar_alm_25_2_200_0_0_0_custom_values.yaml files present in the Artifacts/Scripts directory with the required values as mentioned in OSO Configuration Parameters.
5. Untar the Helm charts tgz file available in the Artifacts/Scripts directory.
```
cd Artifacts/Scripts
$ tar -xvzf <helm charts.tgz file>
```

Run the following command to upgrade the existing OSO release:


$ helm upgrade <OSO release-name for prometheus> <path to the new prom-OSO helm chart> -n <oso-namespace> -f <path to ocoso_csar_prom_25.2.200_custom_values.yaml file>
$ helm upgrade <OSO release-name for alertmanager> <path to the new alm-OSO helm chart> -n <oso-namespace> -f <path to ocoso_csar_alm_25.2.200_custom_values.yaml file>

Note:

To install the alert config feature, see Automated Configuration of NF Alerts.

Post the Helm upgrade a new Prometheus pod spuns up, which is in container creating state. To make it into running state, detach the PVC from old pod in K8s and let it attach to this new upgraded pod.


$ kubectl get deployment -n <oso-namespace>
# Find Prometheus deployment name and replace it in below commands, Both the commands below needs to be run at the same time
$ kubectl -n <oso-namespace> scale deploy <oso-deployment-name> --replicas=0
$ kubectl -n <oso-namespace> scale deploy <oso-deployment-name> --replicas=1

Verify if all the pods are up and running with the latest versions and changes.
Verify if the upgraded OSO is working as expected by performing the Verifying Installation procedure.