feat: expose cluster.helm_oci_auth for private RKE2 bootstrap chart registries - 4345 (!9125) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR leverages sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!1100 (merged)

cluster.helm_oci_url already lets the charts installed by the RKE2 helm-controller (CNI, CoreDNS, MetalLB) be pulled from an OCI registry of the user's choice, but there was no way to supply credentials when that registry requires authentication.

sylva-capi-cluster gains a 'helm_oci_auth' value for this; since the whole 'cluster' map is passed to that chart through 'helm_secret_values', all that is needed here is to declare the value and let the schema accept it:

  cluster:
    helm_oci_url:
      metallb: oci://myprivate.registry.io/charts/metallb
    helm_oci_auth:
      default:
        username: sylva
        password: s3cr3t

Keyed like 'helm_oci_url', plus a 'default' entry applying to every chart. Credentials belong in a values file handled as a secret.

Requires the matching sylva-capi-cluster change.

Note on values.schema.json: it is generated by tools/generate_json_schema.py, which fetches charts/sylva-capi-cluster/values.schema.json from the ref pinned in source_templates. While this MR is under review, source_templates.sylva-capi-cluster temporarily tracks the companion MR's branch (see the TEMPORARY comment in charts/sylva-units/values.yaml), so the schema committed here always reflects the current state of !1100 (merged). Both the pin and this note are removed before merge: once a sylva-capi-cluster release carrying helm_oci_auth exists, source_templates returns to the upstream URL at that tag and the generator reproduces this file with no diff.

Related to #4345 (closed)

#4345 (closed)

Test coverage

Unit tests: 13 new cases in charts/sylva-capi-cluster/tests/helm_oci_auth_test.yaml; suite goes 51 → 64, all passing.

Verified end to end on hardware against a private registry:2 (bcrypt htpasswd, TLS), capm3 + cabpr, SL Micro 6.2:

	management cluster	workload cluster
Cluster / node	Provisioned, Ready	Provisioned, CP 1/1, Ready
Kustomizations	all Ready	34/34
Per-namespace `sylva-helm-oci-auth`	`kube-system`, `metallb-system`	same

Rendered HelmChart on the workload run:

kind: HelmChart
chart: oci://<registry>/sylva-charts/metallb-resources
repo: ""
dockerRegistrySecret:
  name: sylva-helm-oci-auth

The clearest signal is indirect: the node reached Ready while calico was pulled from the private registry with an empty repo:. A credentials failure there means no CNI, so no Ready node.

A full test procedure — including how to push the six charts, the two ways the URL/version mapping goes wrong, and how to prove the registry really is private — is available and can be attached if useful.

AI assistance:
Claude Code (claude-opus-5) was used on this change: exploring how sylva-units passes cluster values through to sylva-capi-cluster, drafting the values/schema additions, and analysing CABPR's behaviour during the review discussion on !1100 (merged). AI-assisted commits carry an Assisted-by: trailer; commits without one are mine alone.

What I verified myself: deployed a management cluster (capm3/RKE2, SL Micro 6.2) against a private registry:2 with TLS and bcrypt htpasswd and confirmed the charts pull with credentials and the nodes reach Ready; re-ran that deployment with a deliberately wrong password to confirm the failure mode; ran the unit tests and the schema generator locally; and reviewed the full diff.

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	Deployment option list and description
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by `mgmt:` or `wkld:` to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment Available platform list and description
⚡	Pipeline control	`autorun`, `manual` or `blocking`. Can be used to override global config and start a deployment pipeline the required way

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Sep 23, 2026 by Jonas Arndt

feat: expose cluster.helm_oci_auth for private RKE2 bootstrap chart registries - 4345

What does this MR do and why?

Related reference(s)

Test coverage

CI configuration

Global config for deployment pipelines

Merge request reports