Skip to main content

Override Chart Values

Everything Racora deploys is set by chart values: the network identity, the registry, placement, image tags, the settings of every component. The installer sets the ones it owns; the rest you override. On the k3s platform your overrides live in one HelmChartConfig; on a cluster you run they live in your values file, passed on every run (Install onto an Existing Kubernetes Cluster). Every value, with its default, is in the chart values reference.

One HelmChartConfig​

On the k3s platform every value you override goes into one object: the HelmChartConfig named racora in kube-system, whose valuesContent k3s's helm-controller layers over the release's values. There is exactly one. Applying a second manifest with that name replaces the first one's valuesContent, so keep everything you override in one file and apply that file: the network identity (Configure the 5G Core), the registry (Use Your Own Registry or Install Offline), a hot-bumped image tag.

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: racora
  namespace: kube-system
spec:
  valuesContent: |-
    global:
      network:                      # only when yours is not the default
        plmn: "90170"
        tacs: [7]
        slices:
          - sst: 1
      systemDefaultRegistry: registry.example.com/racora
    racora-cu:
      cuIp:
        image:
          tag: v0.3.1               # a hot-bump, until the next release pins it

When a release ships the pin you hot-bumped, remove that key from valuesContent and re-apply the file. Never delete the object while it carries your identity or registry: a deleted identity falls back to the default PLMN, and every cell on another PLMN goes PlmnNotServed.

Hot-Bump One Image between Releases​

You don't need a Racora release to bump one image; every image tag is a chart value, keyed by subchart name (racora-cu, racora-controller, racora-core-open5gs, racora-node, racora-monitoring).

k3s platform: the tag goes into the HelmChartConfig above, and helm-controller rolls just that workload.

A cluster you run: in your values file:

# my-values.yaml
racora-cu:
  cuIp:
    image: { tag: v0.3.1 }

then the platform's command with -f my-values.yaml, as on every run: a --set on one run is lost on the next.

Between releases you hot-bump at your own risk; the next Racora release re-pins the set. Remove the hot-bump key once the next release ships, or it silently shadows the new pin.