Skip to content

bug(apps/mariadb): deprecated backup CronJob cannot start — secretKeyRef names a Secret and key that do not exist #3347

Description

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:

  1. 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.
  2. 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.

Activity

  1. added
    kind/bugCategorizes issue or PR as related to a bug
    area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/databaseIssues or PRs related to managed databases (postgres, mariadb, redis, etcd, kafka, clickhouse)kind/bugCategorizes issue or PR as related to a bugpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next releasetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions