feat(charts): take the harbor and vault charts from the registry mirror #207
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/oci-chart-mirror"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What was
Both apps took their chart from a GitRepository of the upstream project, because the upstream chart repositories are unusable from our network:
helm.goharbor.iois served by CloudFront and stalls the transfer (200 withContent-Length: 95085, then ~11 KB in 90 s), andhelm.releases.hashicorp.comanswers 403. A chart taken from a git repository is what no cluster-level check can inflate, so those two releases were the only ones a render-based check could not cover.What this PR does
kubernetes/apps/harbor/harbor/appandkubernetes/apps/security/vault/app: the GitRepository source is replaced by an OCIRepository of our mirror (oci://harbor.grachevko.ru/charts/<name>, the tag is the CHART version), the HelmRelease useschartRefto it, and the kustomization lists the new file instead of the old one.kubernetes/apps/renovate/renovate-operator/app/helmrelease.yaml:install/upgrade.disableSchemaValidation: true. The chart schema wants a hostname inpolicy.allowedHosts, and the value there isgit.${SECRET_DOMAIN}— a valid hostname only after Flux substitutes it, so the release fails schema validation both on install and on upgrade. The field is the Flux API switch for exactly this case, not a hole in the check.Why the CI gate is not in this PR
The gate lives in
feat/flux-local-gateand is opened separately. Its diff job renders the cluster both at the head and at the base branch, and on the current base branch the harbor and vault charts come from a git repository, which flux-local can only inflate from a local path; it fails withunable to detect chart at <workdir>/Chart.yamlwhile rendering main. Measured on run 175 of that workflow:Flux Local - Testsucceeded — that is the whole gate — and only the diff job failed, on the base branch side. In other words the gate needs this change to be merged first, and this change does not need the gate.Verified
flux-local test --enable-helm --all-namespaces --path kubernetes/flux/cluster --sources flux-system=.on this branch: 126 passed, no failures. On main the same command reported 123 passed and 3 failed; with only the Renovate fix 124 passed and 2 failed (harbor and vault). Both mirrored charts are pulled fromharbor.grachevko.ruduring that run, so the OCI sources are proven to inflate.Flux Local - Testjob succeeded there too, which is the same command in the real environment.charts/harbor:1.19.2(sha256:6323d18c...) andcharts/vault:0.34.1(sha256:a8ecf85c...) in Harbor, both pullable anonymously (helm show chart oci://...with no credentials), and the mirroring workflow ran green in grachevko/charts.optional: trueundervalueFrom.secretKeyRefin another app makes the run fail withadditional properties 'optional' not allowed— the class of error the gate exists for.Watch after merge
source-controller has to trust the internal CA to pull from
harbor.grachevko.ru: that certificate is signed by our CA, while the node-level trust (talos/all/55-registry-harbor.yaml) covers kubelet only. If the first reconcile reportsx509: certificate signed by unknown authority, the fix is to give the Flux controllers the sameinternal-caConfigMap the other controllers already mount, rather than weakening the source.Next
feat/flux-local-gateopens as its own pull request once this one is merged.Rollback
Revert the commit: both sources go back to their GitRepository. The charts stay in Harbor, so nothing has to be re-pushed.
## What was Both apps took their chart from a GitRepository of the upstream project, because the upstream chart repositories are unusable from our network: `helm.goharbor.io` is served by CloudFront and stalls the transfer (200 with `Content-Length: 95085`, then ~11 KB in 90 s), and `helm.releases.hashicorp.com` answers 403. A chart taken from a git repository is exactly what no cluster-level check can inflate, so those two releases were the only ones a render-based check could not cover. ## What this PR does - `kubernetes/apps/harbor/harbor/app` and `kubernetes/apps/security/vault/app`: the GitRepository source is replaced by an OCIRepository of our mirror (`oci://harbor.grachevko.ru/charts/<name>`, tag is the CHART version), the HelmRelease uses `chartRef` to it, and the kustomization lists the new file. - `.github/workflows/flux-local.yaml`: the gate. `test` inflates the whole cluster with helm, which validates the values of every HelmRelease against its chart schema, and `diff` renders the HelmReleases at the head and at the base and posts the diff as a pull request comment. The jobs use the upstream composite actions; the runner (Forgejo kubernetes plugin) executes steps inside the pod's `main` container and has no per-step images, which is why the pinned image form used by other repositories is not available here. The `Flux Local - Success` aggregator exists because job-level `success()`/`cancelled()` are not evaluated on this Forgejo version. - `kubernetes/apps/renovate/renovate-operator/app/helmrelease.yaml`: `install/upgrade .disableSchemaValidation: true`. The chart schema requires a hostname in `policy.allowedHosts`, and the value there is `git.${SECRET_DOMAIN}`, which is a valid hostname only after Flux substitutes it; the release therefore fails schema validation on install and on upgrade. The field is the Flux API's own switch for this case, not a way around the check. ## Verified - `flux-local test --enable-helm --all-namespaces --path kubernetes/flux/cluster --sources flux-system=.` on this branch: **126 passed**, no failures. Before the mirror, the same command on main reported 123 passed and 3 failed, and with only the Renovate fix 124 passed and 2 failed (harbor and vault). Both mirrored charts are pulled by flux-local from `harbor.grachevko.ru` during that run, so the OCI sources are proven to inflate. - The mirror itself is live: `charts/harbor:1.19.2` (sha256:6323d18c…) and `charts/vault:0.34.1` (sha256:a8ecf85c…), both pullable anonymously (`helm show chart oci://…` without credentials). Its workflow ran green in grachevko/charts. - Negative control from the same setup: a stray `optional: true` under `valueFrom.secretKeyRef` in another app makes the run fail with `additional properties 'optional' not allowed`, which is the class of error this gate exists for. ## Watch after merge source-controller has to trust the internal CA to pull from `harbor.grachevko.ru`. The certificate of that name is signed by our CA, while node-level trust (talos/all/55-registry-harbor.yaml) covers kubelet only. If the first reconcile reports `x509: certificate signed by unknown authority`, the fix is to give the Flux controllers the same `internal-ca` ConfigMap the other controllers already mount, not to weaken the source. ## Next Renovate does not update the two chart tags yet: it has to read the tags of our Harbor. That is a separate change to the Renovate configuration. ## Rollback Revert the commit: the two sources go back to their GitRepository and the workflow disappears. The charts stay in Harbor, so nothing has to be re-pushed.