You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(postgres,mariadb): list the releases an upgrade would refuse before it runs #4464
Upgrading the postgres and mariadb charts past #4078 can stop individual releases at render time. Four guards refuse values that rendered before: a Postgres database name outside [-._a-zA-Z0-9], a Postgres extension value with a clause after the name (earthdistance CASCADE), a missing MariaDB <release>-credentials Secret, and users.postgres. Each release is its own HelmRelease, so this does not stop the platform upgrade, but each affected release stops converging on its own. The admission warnings #4078 adds fire only on create and update of an Application, so a tenant who never edits their CR gets no signal, and the operator learns about each refusal after the upgrade, one release at a time.
Proposed solution
A read-only preflight that runs the same predicates over the Postgres and MariaDB Applications the apiserver already holds, and prints the releases the new charts would refuse, with the reason and the documented fix for each. Nothing changes at render time; the guards stay as they are. An operator runs it before a platform upgrade and gets one list instead of discovering the refusals release by release.
Open points: where it lives (a hack/ script, a cozypkg subcommand, or a check the operator runs before applying a new platform version), and how the predicates stay in step with the chart guards so the two cannot drift.
Scope check
This affects a single component / package (if it spans many, consider a design proposal)
I can describe the expected behavior concretely (if not, consider a Discussion first)
Alternatives considered
A migration that rewrites the refused values was rejected in #4078: renaming a tenant's database or changing its extension list on their behalf is not safe. Relaxing the guards would reopen the SQL injection they close.
Additional context
Suggested in the review of #4078. The guards and their fixes are listed in that PR's description and in the reject messages themselves.
Activity