Versions and Compatibility
The Version Axes
- Component versions. Every image versions, builds and ships on its own cadence, in the repository where its code lives. A CU-IP fix bumps CU-IP and publishes a CU-IP image; it does not require a Racora release.
- The cluster layer. The k3s platform installs an upstream k3s release, never a
Racora build. Which one is a curated pin (
cluster.k3s.versioninversions.yaml), bumped deliberately, never auto-resolved. - The Racora release.
vX.Y.Zis a curation: one known-good version of every component plus one k3s release, the way a Linux distribution release pins package versions.
versions.yaml names the k3s pin and a fallback version per external component. At tag
time the pipeline resolves each external component to its latest published version, and
the release's chart-values.yaml is the record of what that release pins.
The Image Set
| Group | Built in | Examples |
|---|---|---|
| external | their own repositories | gnb and open5gs (the gNB repository), cuip |
| internal | the racora repository | racora-controller, racora-core-controller, rann-p-forwarder, ettus-device-plugin |
| third-party | upstream, mirrored unmodified | ClickHouse, Tempo, the OpenTelemetry collector, Grafana, the NVIDIA device plugin |
| cluster | the upstream k3s release, mirrored | the k3s binary and its checksum |
All are independently versioned; "internal" only says where the code lives.
What a Release Fixes
A published release is an immutable, self-contained snapshot. The chart carries its
image pins in its defaults, the images sit at immutable tags in one registry
namespace (registry.gitlab.com/cognitive-network-solutions/racora/*, re-rootable with
global.systemDefaultRegistry), the k3s binary is a fixed upstream release, and the
installer that runs on a host is the one packaged with that release: for a release
install, the front door served at get.racora.io only resolves the version and runs the
release's own installer package. On a host Racora installed, a provision-rf or uninstall run uses the persisted copy of
that release's installer (/opt/racora/installer); on any other host it follows
INSTALL_RACORA_VERSION when it is set and the repository's main branch otherwise. Any
release installs its own set, for as long as its images and package files
exist. Published releases start at v0.6.0; the assets a release publishes are on
Release Process, and every release with its pins is on
Release History.
What Upgrades with What
A RAN platform stacks layers that version independently. Naming the layer you mean is what makes an upgrade predictable (Upgrade Racora):
| Layer | What it is | Touches | Mechanism |
|---|---|---|---|
| the cluster platform | k3s: the upstream binary Racora installed; otherwise your distribution | every node's kubelet | k3s: re-run the installer on the control node, and on a worker only when the k3s pin moved; otherwise your platform's procedure |
| the release | the chart with its pinned image set | the pods whose spec changed | k3s: re-run the installer on the control node; otherwise helm upgrade |
| one component image | for example a new CU-IP between releases | one Deployment | override the pin (HelmChartConfig, or your values file on a cluster you run) |
| the CRD schemas | the NRCell and Subscriber APIs | the whole cluster | k3s: re-applied out-of-band by the installer; otherwise inside the release |
| the host layer | the installer, the core provider's host units, provisioning, node labels | each affected node | re-run the installer on that node, or re-provision |
| stateful data | the subscriber database, telemetry | where it is stored | the claim survives; telemetry on emptyDir does not |
A release bump that exists because one image changed touches only the nodes that run it; a CRD change is applied by the installer or the release, never by hand.
Immutability and Retention
- A published tag is never overwritten.
gnb:v0.4.6always means the same image; a change gets a new tag. Pin real version tags, never a floatinglatest. - Old release images are kept. As long as a release's images and package files are in the registries, that release installs.
Hot-bumping one image between releases is a task: Override Chart Values.