The deprecated MariaDB backup CronJob cannot start. Its secretKeyRef names both a Secret and a key that the chart never renders, so the pod fails at container creation and no backup has ever run through this path.
packages/apps/mariadb/templates/backup-cronjob.yaml asks for:
- name: MYSQL_PWD
valueFrom:
secretKeyRef:
name: {{ .Release.Name }}
key: root-password
packages/apps/mariadb/templates/secret.yaml renders {{ .Release.Name }}-credentials, and its keys are the user names — so the root password lives under root. Both halves of the reference are therefore wrong: there is no bare <release> Secret, and no root-password key in the one that does exist. The pod stops at CreateContainerConfigError before the container is created, so nothing in the backup script — including its TLS handling — is ever reached.
This is not a regression: it is the current state of main.
Consequence. An instance configured with backup.enabled: true produces no backups from this path, and the failure is only visible to someone who looks at the CronJob's pods. Anyone who enabled it and did not verify believes they are covered and is not. The backup.* values are marked deprecated in favour of the BackupClass / Plan flow, which is unaffected.
Why this is not a two-token fix. Correcting the reference would start the job on every instance that already has backup.enabled: true — scheduled mysqldump against production and restic writes to S3, beginning at the next upgrade, on instances whose operators have not been expecting either. The repair is small; its operational blast radius is not.
Two directions, both reasonable:
- Repair and announce. The user did opt in by setting
backup.enabled: true, so honouring that request is defensible — but it needs a release note loud enough that operators can disable it before upgrading, and ideally a check that the credentials it will use are still valid.
- Remove the dead path. It is deprecated, it has a working replacement, and nobody can currently be depending on it successfully. Removing
backup.* is honest about what the chart does, at the cost of a values-schema break for anyone still carrying the setting.
Either way the disclosure matters more than the code: operators relying on this path should be told that it has not been running.
The deprecated MariaDB backup CronJob cannot start. Its
secretKeyRefnames both a Secret and a key that the chart never renders, so the pod fails at container creation and no backup has ever run through this path.packages/apps/mariadb/templates/backup-cronjob.yamlasks for:packages/apps/mariadb/templates/secret.yamlrenders{{ .Release.Name }}-credentials, and its keys are the user names — so the root password lives underroot. Both halves of the reference are therefore wrong: there is no bare<release>Secret, and noroot-passwordkey in the one that does exist. The pod stops atCreateContainerConfigErrorbefore the container is created, so nothing in the backup script — including its TLS handling — is ever reached.This is not a regression: it is the current state of
main.Consequence. An instance configured with
backup.enabled: trueproduces no backups from this path, and the failure is only visible to someone who looks at the CronJob's pods. Anyone who enabled it and did not verify believes they are covered and is not. Thebackup.*values are marked deprecated in favour of theBackupClass/Planflow, which is unaffected.Why this is not a two-token fix. Correcting the reference would start the job on every instance that already has
backup.enabled: true— scheduledmysqldumpagainst production andresticwrites to S3, beginning at the next upgrade, on instances whose operators have not been expecting either. The repair is small; its operational blast radius is not.Two directions, both reasonable:
backup.enabled: true, so honouring that request is defensible — but it needs a release note loud enough that operators can disable it before upgrading, and ideally a check that the credentials it will use are still valid.backup.*is honest about what the chart does, at the cost of a values-schema break for anyone still carrying the setting.Either way the disclosure matters more than the code: operators relying on this path should be told that it has not been running.