Upgrade OpenSDN from 24.1 to 25.1

Gazpacho only

OpenSDN provides the software-defined networking layer for MOSK. This procedure describes how to manually upgrade an existing OpenSDN 24.1 deployment to 25.1, including the TFOperator version update and the required restart of the TFVRouter pods.

Prerequisites

Before you begin, verify the following:

Your cluster runs OpenStack Gazpacho. OpenSDN 25.1 is supported only with this OpenStack release. Support for upgrading OpenSDN on other LTS OpenStack releases will be delivered in a future MOSK series.
You have access to a staging cluster where the upgrade has already been tested.
A maintenance window is scheduled, since TFVRouter pod restarts briefly disrupt dataplane networking on each compute node.
You have reviewed the TFOperator custom resource for any pinned image overrides, as described in step 2 below.

Upgrade procedure

To upgrade an existing OpenSDN 24.1 deployment to 25.1:

Create a full cluster backup before making any change. For the backup procedure, refer to Backup and restore OpenStack databases.
Inspect the TFOperator custom resource for pinned image overrides under spec.devOptions (tfImage.tfImageTag and any per-component entries under images), and unpin or update them before proceeding.

Warning

Leaving a component pinned to an OpenSDN 24.1 image can result in a mix of incompatible component versions after the upgrade.
Update the tfVersion field of the TFOperator custom resource from "24.1" to "25.1":
```
kubectl patch tfoperator openstack-tf -n tf --type merge \
  -p '{"spec": {"tfVersion": "25.1"}}'
```
The tungstenfabric-operator reconciles this change by rolling out the OpenSDN 25.1 images to the TFConfig, TFControl, and WebUI components. TFVRouter pods are not restarted automatically and must be restarted manually as described in the next step.

Restart the TFVRouter pods one node at a time so that each pod picks up the OpenSDN 25.1 image without disrupting all nodes simultaneously.

Warning

Do not restart them all at once. Doing so restarts the dataplane on every compute node simultaneously and disrupts networking for all workloads at the same time.

Select one of the following options:

Restart the pods manually, one pod at a time. For each TFVRouter pod, delete it and wait for it to become Ready again before deleting the next one:
```
kubectl delete pod -n tf <tf-vrouter-agent-pod-name>
```

Restart the pods automatically, one node at a time:

for node in $(kubectl get pods -n tf -l app=tf-vrouter-agent \
    -o jsonpath='{.items[*].spec.nodeName}'); do
  kubectl delete pod -n tf -l app=tf-vrouter-agent \
    --field-selector spec.nodeName="$node"
  until kubectl get pod -n tf -l app=tf-vrouter-agent \
      --field-selector spec.nodeName="$node" -o name | grep -q .; do
    sleep 2
  done
  kubectl wait pod -n tf -l app=tf-vrouter-agent \
    --field-selector spec.nodeName="$node" \
    --for=condition=Ready --timeout=300s
done

Monitor the rollout:
```
kubectl get pods -n tf -w
```
Note

As part of this upgrade, BGPaaS routing moves from the vRouter Agent to the Controller. Some transient BGP route churn is expected while the Controller re-establishes routing state.
After the rollout completes, verify that all OpenSDN pods are in the Running state and use the opensdn- prefixed 25.1 images:
```
kubectl get pods -n tf
```

After completing this procedure, all OpenSDN components run 25.1 images, and BGPaaS routing is handled by the Controller instead of the vRouter Agent. Keep the Cassandra backup taken in step 1 until you have confirmed the cluster is stable on 25.1.

Rollback considerations

There is no supported rollback from OpenSDN 25.1 to 24.1 through this procedure. If you need to revert the upgrade, restore the Cassandra backup and redeploy the 24.1 images.