Skip to main content

Change What a Deployment Runs

A Racora release is a baseline, not a boundary. A deployment is that baseline plus what you declared on top of it, and the ways to declare are the ones Kubernetes gives you: the release's values, its custom resources, and whatever you run alongside. None of it needs a new release, and a release upgrade carries all of it forward (Upgrade Racora).

Through Values​

Every value is in the one HelmChartConfig on the k3s platform or your values file on a cluster you run (Override Chart Values):

  • A component's image. global.components.<name> moves one component to another version, from the release's registry or from where its project publishes it (Update a Component). A newer gNB, CU-IP or O1 adapter is one line.
  • The 5G core. global.core.provider selects the bundled Open5GS or external with the AMF you run; the RAN side never learns which (The 5G Core).
  • Placement, the registry, persistence, monitoring, probes: every component's chart values (Chart Values).

Through Cells and Subscribers​

Cells are NRCell objects, SIMs are Subscriber objects, radios are radio-profile ConfigMaps a cell refers to (Deploy Cells, Add Subscribers, Radios). They are durable across upgrades.

Alongside​

Anything else is plain Kubernetes: your own workloads, in their own namespaces and their own Helm releases, next to Racora's. The seven namespaces the release creates and the objects the charts and the controller render belong to the release; edit those through values and cells, not in place, because helm re-applies the chart's objects on the next upgrade and the controller re-asserts a cell's DU Deployment on its next reconcile.

A Changed Chart​

When a change is to what the deployment is made of rather than to a value, a new service, a sidecar, a template, a core provider module, the chart itself changes, and the deployment takes your chart the way it takes a release. From a checkout of the repository with your change:

bash scripts/package-chart.sh                 # dist/racora-<version>.tgz, pins baked
sh scripts/build-crds.sh dist/racora-crds.yaml

Images the tree changed are built with their component's Dockerfile and tagged as versions.yaml names them; put them where the nodes pull from, or import them on each node (sudo k3s ctr images import on the k3s platform).

k3s platform, on the control node, from that checkout:

INSTALL_RACORA_VERSION=vX.Y.Z RACORA_CHART_TGZ=dist/racora-<version>.tgz \
  RACORA_CRD_FILE=dist/racora-crds.yaml sh install-racora.sh

INSTALL_RACORA_VERSION names the baseline release (its k3s pin and installer package); RACORA_CHART_TGZ and RACORA_CRD_FILE carry your payload instead of the release's. The run is an in-place upgrade like any other: the pre-flight dry-runs your chart in the cluster, reports what rolls, and helm-controller applies it with the same failure semantics (Upgrade Racora).

A cluster you run: the platform's command with your package in place of the OCI chart and version:

helm upgrade --install racora dist/racora-<version>.tgz --namespace default --reset-values \
  -f installer/platforms/kubernetes/values.yaml -f installer/cores/<provider>/values.yaml -f my-values.yaml

Going back is installing the release again.

What Stays Compatible​

Racora drives the interfaces the pinned components offer: the gNB's configuration schema and the runtime commands the controller sends the CU-CP, the O1 adapter's provisioning file, the core provider's subscriber adapter. A newer component that keeps those interfaces and adds to them, a faster protocol layer, more runtime commands, keeps working as a component update, and the deployment gets the improvement; Racora drives the new capabilities once a release adds that. A component that renames or removes an interface Racora drives needs a Racora release, which is what a release absorbs.