Should helm upgrade apply Hasura migrations and metadata?

[mosoriob]

Question

Must the MINT Helm chart apply database changes at helm upgrade?

Today it does not. charts/mint/templates/post-install-hasura.yaml is a post-install hook. It runs hasura migrate apply && hasura metadata apply && hasura seeds apply. It runs at a new install only. A helm upgrade ships new images and no schema change.

Found while resolving #99. That fix needs a migration at TACC. The deploy path cannot deliver it, so a person must run the SQL by hand. That is #116.

Why a new job, and not a new annotation

You cannot add post-upgrade to the current job. The job also applies seeds. There are 26 seed files and 24 MB of data. No seed file uses ON CONFLICT. A second run causes a primary key error. Seeds run last, so the job fails after the useful work lands. Helm then marks the release as failed.

So the proposal is a new job. It runs migrate apply and metadata apply. It does not run seeds.

What to decide

1. Migrations, metadata, or both? The two are not equally safe. migrate apply adds to the schema. metadata apply replaces the metadata. A person may have changed permissions in the TACC console. The job removes those changes without a word. An option is to automate migrations only, and to keep metadata manual.

2. Does the job run at every upgrade? The flip (#77) is an upgrade. It is the only step on the map that you cannot reverse. An automatic job applies every pending migration at that moment. Nobody reads them first.

3. What is the rollback? helm rollback returns the manifests only. It does not return the database. The chart has no pre-rollback or post-rollback hook, so nothing runs down.sql. A failed upgrade leaves the old app on the new schema. The rollback for data is a dump and a restore. See backups/production-backup.sql and graphql_engine/scripts/restore.sh.

4. Which clusters? ISI, TACC and mint.local are at different migration versions. A job that is safe at one may not be safe at another.

Measure first

Two facts are unknown, and both change the answer:

• The migration version at TACC. The mint.local dev cluster is at 1771200016000, which is the tip of graphql_engine. TACC is not verified.
• Metadata drift at TACC. Use hasura metadata diff.

#116 starts with these two reads. Do them before you decide.

Scope

This ticket must not delay the flip. The destination of the map is client sign-off. Deploy machinery is not on that route. Rule this out of scope if it starts to hold up #77.