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

What does this MR do and why?

This MR uses sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!1100 (merged), released in sylva-capi-cluster 0.15.18.

The sylva-core CI pulls the metallb chart with cluster.helm_oci_auth credentials since ci-deployment-values 0.6.34 (sylva-projects/sylva-elements/ci-tooling/ci-deployment-values!520 (merged)); SYLVA_CI_VALUES_REVISION is set to that tag here.

Replaces !9125 (closed), which was opened from a fork; the pipelines do not support fork-based MRs, so the same commits now come from a branch in this project.

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.

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 61 → 74, all passing.

CI: with ci-deployment-values!520, every RKE2 CI deployment pulls the metallb chart with credentials. registry.gitlab.com rejects wrong credentials, so a regression breaks the deployment. Verified in deployment pipeline https://gitlab.com/sylva-projects/sylva-core/-/pipelines/2882114422 (capm3/RKE2/SUSE): it used the !520 (merged) branch, the cluster values of both clusters contain helm_oci_auth.metallb, both control planes carry /opt/sylva/rke2/manifests/helm-oci-auth-metallb-system.yaml, and both clusters deployed successfully.

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 29, 2026 by Thomas Morin

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