feat(stalwart): take our own published valkey chart as the subchart
Validate Helm Charts / Detect changed charts (pull_request) Successful in 7s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Build stalwart (pull_request) Successful in 17s
Validate Helm Charts / Trivy config stalwart (pull_request) Successful in 17s
Install-test / Install-test stalwart (pull_request) Successful in 1m36s
Validate Helm Charts / Install-test (pull_request) Successful in 1m36s
Validate Helm Charts / Detect changed charts (pull_request) Successful in 7s
Validate Helm Charts / Resource quantities (pull_request) Successful in 12s
Validate Helm Charts / Build stalwart (pull_request) Successful in 17s
Validate Helm Charts / Trivy config stalwart (pull_request) Successful in 17s
Install-test / Install-test stalwart (pull_request) Successful in 1m36s
Validate Helm Charts / Install-test (pull_request) Successful in 1m36s
Replaces the dependency on upstream's valkey chart with this repo's own, resolved from the published index: version: "1.0.0+up9.1.2.alpine" repository: "https://git.jk-dev.de/api/packages/jlab-cluster/helm" The condition is "valkeySubchart.enabled", NOT "valkey.enabled", and that is forced rather than stylistic. Everything under "valkey:" is handed to the subchart as its values and validated against ITS schema, and our valkey chart ships additionalProperties: false with no "enabled" property - so "valkey.enabled" is rejected by the subchart: valkey: - at '': additional properties 'enabled' not allowed Measured. And because Helm skips a DISABLED subchart's schema validation, that error would have surfaced only for whoever first set it to true: every render, lint and install-test in CI would have stayed green. Adding "enabled" to valkey/values.schema.json was rejected as the repair - that chart does not read the key, and it would have needed its own PR and a publish first. The host helper was also wrong for our chart and is fixed: our Service is "<release>-valkey-service", not upstream's bare "<release>-valkey". The values block is rewritten for our chart's schema, with the pair chosen rather than inherited: CACHE (persistence off + allkeys-lru), because everything Stalwart keeps in the in-memory store - rate limiters, auth tokens, sessions, auto-ban entries, coordination pub/sub - is reconstructible, and the node-id lease lives in the data store. The cost is named where it is set: with allkeys-lru the rate limiters and the auto-ban FAIL OPEN under memory pressure, so the answer is to size memory, not to switch to noeviction (which would make writes error and take out authentication instead). secrets.authSecretRef wants an item whose single field "auth-conf" holds the complete "requirepass <pw>" line, not a bare password. Chart.yaml's comments are corrected where they became false: nothing is "consumed as it comes" any more and there is no shortfall of someone else's to document. The Renovate reasoning stays and is now backed by measurement. New trap, in Chart.yaml and in three places in the wiki: NEVER change valkey/ and a chart depending on it in the same PR. The dependency resolves from the published index, so a combined PR lints, packages, renders AND install-tests against the OLD subchart - green on an artifact that is not the one in the diff. Two consecutive PRs. Two things measured, not assumed, because either could have broken the update path with no symptom but "no updates ever": - helm dependency update AND build resolve the exact build-metadata version from the URL alone with an EMPTY HELM_REPOSITORY_CONFIG - a fresh runner's state - so the anonymous index needs no credential and ci/helm-dependencies.sh is untouched; - Renovate 44.132.2 dry run with the dependency pinned low: manager helmv3 matched the file, took registryUrls from Chart.yaml and offered newVersion "1.0.0+up9.1.2.alpine", versioning "helm". The self-hosted index and the "+up..." suffix are both handled. README: the claim "no registry address appears in this repository" is narrowed to what still holds - the publish target and its credentials come from 1Password and are not in the repo. The read path is now in Chart.yaml by necessity, carries no credential, and the host was always in CLAUDE.md. Done here rather than later so the paperless PR finds it already corrected. Re-verified after the change: helm lint --strict (0 failed), helm package (the subchart is embedded in the .tgz), helm template with the subchart OFF and ON (ON was previously impossible), against CI test-values, the rendered config.json, ci/run-quantity-render-test.sh (0 failed), NOTES.txt through the scratch-ConfigMap trick, and the fail paths including the reworded abort. The rendered subchart Service name matches what the helper emits, the cache pairing really renders (maxmemory-policy allkeys-lru, appendonly no, save "", emptyDir) and no PVC appears. Part of #65
This commit is contained in:
6 files changed
+226
-68
No files matched your search
@@ -236,18 +236,40 @@ NO INGRESS
|
||||
ingress.domain STAYS REQUIRED even so — the mail Certificate reads it for its
|
||||
dnsNames, and without it the certificate would carry no name at all.
|
||||
{{- end }}
|
||||
{{- if .Values.valkey.enabled }}
|
||||
{{- if .Values.valkeySubchart.enabled }}
|
||||
|
||||
THE VALKEY SUBCHART IS ENABLED
|
||||
Reachable at {{ $valkeyHost }}:{{ .Values.externalServices.valkey.port }}, and it is upstream's chart consumed as it
|
||||
comes. Two of its defaults fall short of this repo's conventions and are NOT
|
||||
patched by us: auth.enabled is false (unauthenticated access from anything
|
||||
the CNI permits), and its NetworkPolicy is its own object with its own
|
||||
semantics, which this chart's networkPolicy block does not reach. See the
|
||||
valkey section of values.yaml.
|
||||
Reachable at {{ $valkeyHost }}:{{ .Values.externalServices.valkey.port }} — this repo's own valkey chart,
|
||||
pulled from the published index. Enter that address as the in-memory store in
|
||||
step 3; the coordinator's Default variant reuses the same connection.
|
||||
|
||||
scaleDown and checksum/config stop at the subchart boundary, and a new Valkey
|
||||
release reaches you only when this chart is republished.
|
||||
ITS 1PASSWORD ITEM IS A SEPARATE ONE, AND ITS FIELD IS NOT A PASSWORD:
|
||||
valkey.secrets.authSecretRef points at
|
||||
{{ .Values.valkey.secrets.authSecretRef | default "<NOT SET - the subchart's own required() will abort the render>" }}
|
||||
and that item carries ONE field, "auth-conf", whose value is the complete
|
||||
configuration line
|
||||
|
||||
requirepass <password>
|
||||
|
||||
not a bare password. The valkey chart mounts the file and includes it, and
|
||||
an init container refuses to start the pod unless the line is really there —
|
||||
because the alternative failure is an open server that looks healthy.
|
||||
|
||||
IT IS CONFIGURED AS A CACHE, NOT A QUEUE
|
||||
persistence.enabled false + maxmemoryPolicy allkeys-lru. Everything Stalwart
|
||||
keeps here — rate-limiter counters, auth tokens, sessions, auto-ban entries,
|
||||
the coordination pub/sub — is reconstructible after a restart; nothing in it
|
||||
is the system of record.
|
||||
|
||||
The cost of allkeys-lru, so it is not a surprise: under memory pressure keys
|
||||
are discarded, so the rate limiters and the auto-ban FAIL OPEN. Size memory
|
||||
for the working set rather than switching to noeviction — with noeviction
|
||||
Stalwart's writes to the store start erroring, which takes out
|
||||
authentication instead of just the limits.
|
||||
|
||||
scaleDown and checksum/config stop at the subchart boundary, so scaling this
|
||||
release to zero does NOT stop the Valkey, and a new valkey chart release
|
||||
reaches you only when stalwart itself is republished.
|
||||
{{- end }}
|
||||
{{- if not .Values.networkPolicy.enabled }}
|
||||
|
||||
|
||||
Reference in new issue
Block a user