Three changes, all about values that do not do what they promise:
1. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }}. The key already existed in
values.yaml with default true but was never read, so switching it off
did nothing. Both required() calls for domain and clusterIssuer live
inside the Ingress file, so gating also removes the contradiction that
one had to supply a domain and issuer in order to turn off an Ingress
one does not want.
2. Null-safety for hardening, probes and resources (#99): an override
written without children is YAML null and erased the whole default
sub-tree, rendering "securityContext: null" - an unhardened container
that starts and reports healthy.
3. values.schema.json types (#68 + #99): the blocks covered by the
null-safety accept null. This is load-bearing only for keys that have
no chart default (e.g. resources.limits): there Helm has nothing to
delete, so the null survives into schema validation and a strict
"object" type rejected it outright.
Rendering with normal values is byte-identical to 7.0.0.
Prints what an operator would otherwise have to look up after installing:
the rendered Ingress URL, the cert-manager Certificate to watch while the
browser still warns, and the fact that the chart needs no secrets and no
volumes.
Adds three warnings that the values alone do not tell: CyberChef ships no
authentication, so everything that reaches the URL can use it; the app is
static and holds no server-side state, so upgrades and rollbacks need no
migration; and cyberchef.env reaches nginx but never the served bundle.
Scaled-down installations are called out conditionally, naming whichever of
scaleDown / cyberchef.replicas caused it, via the chart's own replicas
helper so the notice cannot drift from the rendered Deployment.
The URL is only ever rendered from .Values.ingress.domain, so no domain is
stored in the chart. Refs #43.
Third change of the same class (#99): an override written without
children is YAML null and replaced the whole default sub-tree, rendering
"securityContext: null" (unhardened container), a vanished probe or a
container without resource accounting - silently, while the workload
reports healthy.
The defaultedDict helper from #96 is adopted for both workloads, so an
empty block means "chart defaults apply" while an explicitly set value
still wins, including false and 0.
The server probes rebuild their Host header from ingress.domain via the
passed-in root context, because the 2.x server rejects requests whose
Host is neither loopback nor a CORS_ORIGIN host.
The schema types allow null for exactly these blocks, so schema and
helper agree instead of the schema rejecting what the helper absorbs.
Rendering with normal values is byte-identical to the previous version,
with and without the guacd sidecar.
Two changes, both about values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored.
2. Null-safety for hardening, probes and resources (#99): an override
written without children is YAML null and replaced the whole default
sub-tree, rendering "securityContext: null" (unhardened container), a
vanished probe or a container without resource accounting - silently.
The defaultedDict helper from #96 is adopted so an empty block means
"chart defaults apply", while an explicitly set value still wins,
including false and 0.
The schema types allow null for exactly these blocks, so the two changes
agree instead of the schema rejecting what the helper is meant to absorb.
No ingress gate here: this chart already gates its Ingress correctly.
Rendering with normal values is byte-identical to the previous version.
Major bump: a schema can break existing deployments that carry dead keys.
Two changes of the same class - values that do not do what they promise:
1. values.schema.json (#68): additionalProperties: false on every
chart-owned object level, so a key the chart does not read is rejected
at render time instead of being silently ignored. Objects passed
verbatim into the pod spec (probes, securityContext, global) stay open.
2. Ingress gate (#93): the Ingress template is wrapped in
{{- if .Values.ingress.enabled }} and the key is added to values.yaml
with default true, so behaviour is unchanged. Without the gate the
value did not exist at all and could not switch the Ingress off.
Major bump: a schema can break existing deployments that carry dead keys.
The chart mounted no volumes at all while running with
readOnlyRootFilesystem: true, so every Next.js write to
/app/apps/web/.next/cache failed. The image optimizer's failure even
surfaced as an unhandledRejection, so this was more than log noise.
The cache path is now a writable emptyDir; path and an optional
sizeLimit are configurable under rallly.cache. The hardening is
untouched — the pod's existing fsGroup (1000) is what makes the mounted
volume writable for uid 20000.
Verified in a throwaway k3d cluster which paths the app actually writes:
with a fully writable root filesystem and the cache mounted, the only
path the container touches is the cache directory itself. /tmp, $HOME
(=/app) and the rest of the root filesystem stay untouched, so no second
mount is needed.
Also drops the vestigial "capabilities.add: []": Trivy's AVD-KSV-0022 for
rallly (#84) comes from the older chart version deployed in the cluster,
which rendered a null list entry under add:. Reproduced with trivy config
against both renderings; the app needs no capabilities.
Major bump: runtime behavior changes, a volume is added.
Fixes#60
A "barcodes:" key left without children (e.g. after deleting the last
remaining sub-key, PAPERLESS_CONSUMER_BARCODE_SCANNER, which paperless-ngx
3.0 removed) is YAML null and replaced the whole default sub-tree on merge.
Rendering then failed on the nil pointer, so the release simply stopped
updating.
An empty or null block now means "the chart defaults apply". The merge runs
through a new paperless-ngx.defaultedDict helper: nulls never delete, nested
maps merge recursively, and explicitly set values win - including false and 0,
which "default" and "mergeOverwrite" would swallow. A scalar where the
defaults define a map is rejected with the values path in the message.
Major bump: the meaning of a values override changes.
Fixes#61
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
Home Assistant reads configuration.yaml, http-config.yaml and
recorder-config.yaml from a 1Password-backed Secret, mounted with subPath.
Two different gaps hide behind that, and only one of them can be closed.
Repointing secrets.configSecretRef at a different vault item used to leave the
running pod on the old configuration. That is now covered: the pod template
carries checksum/secret-ref over the rendered OnePasswordItem. The annotation
is named apart from checksum/config on purpose - it only promises that the
config source changed, not the config itself - matching the pattern
minecraft-server introduced.
Changing the CONTENT of the item in the vault still does not restart anything,
and cannot: Helm never sees the content, so there is nothing to hash. The
operator's own auto-restart annotation is no way out either - onepassword-
operator 1.12.0 enumerates exactly one workload type in its secret-update
handler (appsv1.DeploymentList) and this workload is a StatefulSet, so the
annotation would be a silent no-op advertising a guarantee it cannot keep. It
is deliberately not set. values.yaml states the limitation and the manual
rollout restart it requires; the README guideline records the operator finding,
the annotation precedence trap, and the checksum/secret-ref pattern so neither
is rediscovered the hard way.
Major bump: runtime behavior changes - changing the secret reference now costs
a restart. For this release the effect is preventive, since it currently runs
at zero replicas via scaleDown.
Last of the three publishes that carry the checksum annotations from
3.0.0+up2026.8.2.java8, leaving main on the line of the only running server.
Same chart content as the java8 and java17 publishes, only the published Java
line changes: appVersion moves to the dated tag 2026.8.2-java21 and the
minecraft.version default moves to 1.21.1, the version ftb-skies-2 actually
runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need
Java 21).
Against the state before this series (2.0.0+up2026.8.2.java21) the only
replaced line in Chart.yaml and values.yaml is the chart version; appVersion
and the minecraft.version default are byte-identical, everything else is
additive.
Refs #82.
additionalProperties: false on every chart-owned object level, so a key
the chart does not read is rejected at render time instead of being
silently ignored. Objects passed verbatim into the pod spec (probes,
securityContext, global) stay open - Kubernetes owns their schema there.
Major bump: a schema can break existing deployments that carry dead keys.
Refs #68
Second of the three publishes that carry the checksum annotations from
3.0.0+up2026.8.2.java8. Same chart content, only the published Java line
changes: appVersion moves to the dated tag 2026.8.2-java17 and the
minecraft.version default moves to 1.20.1, the line's matching Minecraft
version (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need
Java 21).
Refs #82.
smb.conf is rendered from samba.shares and mounted with subPath, so adding,
renaming or re-scoping a share rewrote the ConfigMap while the running smbd
kept its old share list: the pod template was unchanged, nothing restarted,
and the kubelet does not refresh subPath mounts. The share simply did not
exist for clients while the release looked healthy - the failure mode from #82.
The pod template now carries checksum/config over the rendered ConfigMap.
users.conf cannot be covered the same way: it comes from a 1Password-backed
Secret whose content Helm never sees, and the operator's auto-restart only
handles Deployments, not this StatefulSet. values.yaml now documents that
limitation and the manual rollout restart it requires.
Major bump: runtime behavior changes - a share change now costs a restart of
the samba pod, which drops open SMB sessions (share data lives on PVCs and is
unaffected).
The StatefulSet now carries two annotations over its two configuration
sources, so a change to either produces a new pod template and a controlled
restart:
checksum/config the rendered ConfigMap (init.sh) - complete, Helm sees
the whole content
checksum/secret-ref the rendered OnePasswordItem - the op:// item path only,
because the Secret's content is materialized by the
operator and is unknown to Helm at render time
Two separate annotations rather than one combined hash: they carry different
guarantees, and a single number would blur "covers everything" and "covers the
path but not the content" into one value that nobody can interpret in a
kubectl describe.
The operator's own operator.1password.io/auto-restart is deliberately NOT set:
it restarts Deployments only. Verified in the operator source (main, 9c3b1b9):
restartWorkloadsWithUpdatedSecrets lists nothing but appsv1.DeploymentList and
getPodTemplate has a single case for *appsv1.Deployment. On this StatefulSet
the annotation would be inert while suggesting the opposite, so the remaining
gap - a rotated value inside the vault item - is documented in values.yaml
instead.
First of the three stage-3-style publishes, so the java8 line goes first and
main ends up on java21. Only the published Java line differs between them:
appVersion 2026.8.2-java8 and the matching minecraft.version default 1.12.2.
Major bump: runtime behaviour changes. A configuration change now costs a full
server restart - 124 s measured for ftb-skies on Longhorn.
Refs #82.
The delegation nginx serves the .well-known documents from an nginx.conf that
is rendered from ingress.domain and mounted with subPath. Changing the domain
rewrote the ConfigMap but left the running pod untouched: the pod template was
unchanged, so nothing rolled, and the kubelet never refreshes a subPath mount.
The pod kept serving the old delegation while looking perfectly healthy - the
failure mode from #82.
The pod template now carries checksum/config over the rendered delegation
ConfigMap, so a changed nginx.conf rolls the deployment.
Also documents the limit that remains for homeserver.yaml: it comes from a
1Password-backed Secret, whose content Helm never sees, and the operator's own
auto-restart only ever covers Deployments - not this StatefulSet. That case
needs a manual rollout restart, which the values.yaml now says out loud.
Major bump: runtime behavior changes - a delegation config change now costs a
restart of the nginx pod (a few seconds, no persistent state).
The deployment now carries a checksum/config annotation over the rendered
ConfigMap, so a changed routing table produces a new pod template and a
controlled rollout.
Without it a mapping change was inert but looked successful: the file is
mounted with subPath (kubelet never refreshes those in a running container)
and mc-router reads ROUTES_CONFIG only at startup. That combination caused the
minecraft-server stage-3 outage - the ConfigMap pointed at the renamed
services, the running router kept proxying to the old ones, and the pod stayed
Ready throughout.
Major bump: runtime behaviour changes. A mapping change now costs a router
restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which
clients cannot connect. That restart is what makes the change take effect at
all.
Refs #82.
A changed ConfigMap did not restart any pod in this repo: no chart carries
a checksum/config annotation, so the pod template stays identical and the
running container keeps its old config. With subPath mounts (the usual form
here) the kubelet never refreshes the file either, so the change is silently
ineffective - see #82, where this caused a real outage while every bundle was
green and the pod Ready.
template-chart is the reference implementation, so it gets the annotation on
both pod templates (Deployment and StatefulSet), and the README style guide
gets a new binding section 9 covering the rule, the reason, and the limit for
1Password-backed Secrets.
Major bump: runtime behavior changes - a config change now costs a restart.
Last of the three stage-3 publishes, leaving main on the line of the only
running server. Same chart content as 2.0.0+up2026.8.2.java8 and .java17, only
the published Java line changes: appVersion moves to the dated tag
2026.8.2-java21 and the minecraft.version default moves to 1.21.1, the version
ftb-skies-2 actually runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17,
1.20.5+ need Java 21).
Second of the three stage-3 publishes. Same chart content as
2.0.0+up2026.8.2.java8, only the published Java line changes: appVersion moves
to the dated tag 2026.8.2-java17 and the minecraft.version default moves to
1.20.1, which is the line's matching Minecraft version (Java 8 runs up to
1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21).
Stage 3 of the Fleet migration. Two changes, both breaking, hence the major
bump from 1.0.0 to 2.0.0.
Dated image tags: appVersion moves from the rolling line tag "java8" to the
immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt
continuously, so a pod restart could pull a different image than the previous
start without that being recorded anywhere. 2026.8.2 is the newest upstream
release (published 2026-08-23) and exists for all three Java lines.
Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST)
in both positions, so minecraft.whitelist.enabled: false actually switches the
whitelist off. Previously the chart only emitted whitelist variables while
enabled was true and had no way to express "off" - and because server.properties
lives on the PVC, a release that had once written white-list=true kept it
forever. players stays guarded by enabled, since a non-empty WHITELIST enables
the whitelist in the image regardless of ENABLE_WHITELIST.
The default flips from enabled: true to enabled: false. Under the corrected
semantics the old default (enabled with an empty player list) would mean a
server nobody can join; false matches both the image and vanilla Minecraft.
PR C of three, and the last of the stage-2 sequence. Same chart as
1.0.0+upjava8 and 1.0.0+upjava17, published for the third Java line, so
main comes to rest on the line of the only server that is actually
running.
minecraft.version moves with it (1.20.1 -> 1.21.1): a Minecraft version
only runs on a matching JVM, and 1.20.5+ needs Java 21. This default now
equals what ftb-skies-2 sets in its own values file, so the install-test
boots the production version rather than an arbitrary Java-21-capable one.
The CI values deliberately do not override minecraft.version, so this
default is what the install-test exercises.
PR B of three. Same chart as 1.0.0+upjava8, published for the second Java
line: appVersion selects the image tag, so the JVM is fixed per published
chart version.
minecraft.version moves with it (1.12.2 -> 1.20.1), because a Minecraft
version only runs on a matching JVM: Java 8 goes up to 1.16.5, 1.18-1.20.4
need Java 17. Since 1.0.0 this default is no longer overridden in the CI
values, so the install-test boots exactly this version and a mismatched
default would fail CI instead of passing on a CI-only override.
Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime
behaviour changes (probes, hardening) and the values interface breaks
(resource renames, strict schema).
Two real bugs first:
- The container declared port 35565 while the Service targeted 25565. It
only worked because targetPort was numeric. Both are now server.port
(25565) and the Service targets the named port.
- The download-serverpack init container was guarded by the map
.Values.curseforgeServerpack instead of .enabled, so it rendered for
every release and silently no-opped on an empty wget URL.
Conventions:
- Resources renamed to <release>-<chart>-<kind>, templates to
<app>.<kind>.yaml. The PVC deliberately keeps its historical name -
renaming it would provision a new, empty volume and orphan the worlds.
- Probes (liveness/readiness/startup) via the image's own mc-health, so
Ready means the server answers a server-list ping. Startup budget 20 min.
- Hardened, values-configurable security contexts: non-root uid 1000,
read-only root filesystem with an emptyDir at /tmp, all caps dropped.
- Resources from values with the limitFactor helper; an unset memory
request is derived from the JVM heap so the two cannot drift apart.
- Additive env block rendered through tpl, pinned init image, storage
class as a value, RCON wiring only when actually enabled.
- curseforge/ftb/curseforgeServerpack are now mutually exclusive.
- minecraft.version is pinned to the Java line instead of LATEST.
- The mc-router auto-discovery annotation is gone; the service type it
implicitly switched is now the explicit value server.service.type.
Schema pilot (#68): values.schema.json with additionalProperties false on
every chart-owned level, rejecting all three known dead keys.
Last of the three Java-line publishes; main comes to rest on java21, the line
of the only running server, and the registry holds all three tags.
Only the two version lines in Chart.yaml change. Because the source chart in
cluster-config is itself on java21, this final state renders byte-identical to
it for mc-ftb-skies-2 with its real values file - the published end state is
exactly what cluster-config runs today.
The CI install values move along with the appVersion, as in the java17 PR:
the JVM is fixed per published chart version and no single Minecraft version
boots on all three lines. Since the chart has no probes, a version the JVM
cannot load would crash after the rollout returned and still leave a green
install-test behind. minecraft.version therefore moves 1.20.1 -> 1.21.1, which
is also what ftb-skies-2 sets in its real values file, so CI exercises the
production version. ci/ is outside the chart directory and is neither packaged
nor published.
jklein