Skip to main content

Change an Element's Configuration over O1

Every element carries an O1 NETCONF server whose datastore is the element's configuration (O1 and the SMO Functions). The examples use the cell nr-n78-b210 of Deploy Cells, PCI 1. The controller carries a command line for it. It runs inside the controller pod, with the O1 account the chart mounts there, against a cell's DU (--cell <name>) or a CU plane (--element cu-cp or cu-up).

The NRCell stays the declaration. A change over O1 to what the cell declares holds until the DU pod starts again; to keep it, change the NRCell. What the cell does not declare, a performance job for instance, is kept across pod starts.

Read the Datastore​

kubectl -n racora-system exec deploy/racora-controller -- \
  python -m racora_controller.o1_client get --cell nr-n78-b210 --path GNBDUFunction/NRCellDU/attributes/nRPCI
GNBDUFunction[id=du1]/NRCellDU[id=nrcelldu1]/attributes/nRPCI = 1

Every leaf prints as its path and value. A path is the datastore's node names from the managed element down, without namespaces; a list entry is named by its id, PerfMetricJob[id=racora-default], and the id may be left out when the list has one entry. Without --path the whole datastore prints; --raw prints the XML the server sends.

Change a Leaf​

set takes one or more PATH=VALUE and sends them as one edit:

kubectl -n racora-system exec deploy/racora-controller -- \
  python -m racora_controller.o1_client set --cell nr-n78-b210 GNBDUFunction/NRCellDU/attributes/nRPCI=2

A leaf that does not exist yet is created under the deepest node of its path that does, and a list entry under its id. A new performance job is one edit with its four attributes:

J='GNBDUFunction/PerfMetricJob[id=smo-test]/attributes'
kubectl -n racora-system exec deploy/racora-controller -- \
  python -m racora_controller.o1_client set --cell nr-n78-b210 \
  "$J/administrativeState=UNLOCKED" "$J/granularityPeriod=1" "$J/performanceMetrics=*" \
  "$J/streamTarget=http://o1-collector.racora-smo.svc.cluster.local:8080/pm/stream?element=nr-n78-b210"

delete removes a node (a leaf, a container or a list entry):

kubectl -n racora-system exec deploy/racora-controller -- \
  python -m racora_controller.o1_client delete --cell nr-n78-b210 'GNBDUFunction/PerfMetricJob[id=smo-test]'

edit --xml FILE merges a ManagedElement fragment you wrote (- reads it from standard input). The server validates every edit against its models and refuses one that does not fit them; the command prints the server's error and exits 1.

What the Element Does​

The element's adapter applies the change:

  • A performance job is applied at runtime; the gNB keeps running.
  • A change the gNB reads only at start, the cell's PCI for instance, makes the adapter restart the gNB container. The pod and its datastore stay, so the gNB starts on the changed configuration; the cell drops for the restart.

What the Cell Reports​

Within racora-controller.o1.checkSeconds the cell's conditions follow (NRCell Status):

kubectl -n racora-system get nrcell nr-n78-b210 \
  -o jsonpath='{range .status.conditions[?(@.type=="O1Config")]}{.status}/{.reason}: {.message}{"\n"}{end}'
  • After the PCI change: False/Drifted, naming nRPCI: 1 -> 2, and a Warning Event O1ConfigDrifted on the cell.
  • After the new performance job: True/InSync, counting the leaves added over O1.

When the DU pod starts again (a node restart, a pod delete, an NRCell change that rolls the DU), its datastore is seeded from the NRCell: the PCI is 1 again and the cell is InSync, and the controller merges the performance job back in.