chore: postgres 17 upgrade

[DerekRoberts]

All files are in the ./db folder. Steps are expected to be run accordingly.

./rename_deployment.sh <source-deployment-name> [target-deployment-name]

• exports a deployment manifest
• deletes fields (status, some metadata)
• modifies deployment (name, labels)
• redeploys the renamed deployment
• watches rollout to completion/failure
• deletes the old deployment, maintains its pvc

./db_transfer.sh <source-deployment-name> <target-deployment-name>

• verifies that source PVC is older than destination PVC (allows override)
• streams pg_dump to pr_restore between postgres containers
• excludes postgis schemas (tiger, tiger_data, topology)

Steps:

# Set target to `819` (this PR), `test` or `prod`
TARGET=819

# 1. Scale down api
oc scale deployment fom-${TARGET}-api --replicas=0

# 2. Rename the old db
cd db
./rename_deployment.sh fom-${TARGET}-db

# 3. Deploy the new db
oc process -f openshift.deploy.yml -p ZONE=${TARGET} -p TAG=${TARGET} | oc apply -f -

# 4. Verify PostGIS extension version = 3.6
oc exec -i deployment/fom-${TARGET}-db -- bash -c "psql -U \$POSTGRES_USER -d \$P
OSTGRES_DB -c 'SELECT PostGIS_Version()'"

# 5. Stream dump from old to new db
./db_transfer.sh fom-${TARGET}-db-prev fom-${TARGET}-db

# 6. Scale up api
oc scale deployment fom-${TARGET}-api --replicas=3

Before merge:

• We need to run these steps on TEST and PROD
• Uncomment/restore image in template (temporarily patched)

---

Thanks for the PR!

Deployments, as required, will be available below:

• api
• admin
• public

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are deployed in:

• Merge Workflow

[ianliuwk1019]

Thank you Derek!
Some comments, may mostly due to I am not clear for the procedure.

• The "steps" in this PR summary probably can be in some readme in db so the developers have idea how to follow to run manual scripts.
• Are the shell scripts required for elevated access to OpenShift to execute them?
• Not clear how it can be rollback if error happens? Or pointing back to old pvc/deployment?
• Is it ok if we can test this in PR (dev) environment first, by: testing from v13 -> v16 -> dummy trigger (regular) deployment (within pr) -> then v17 (just to be safe to see the process works)?

[DerekRoberts]

Thank you Derek! Some comments, may mostly due to I am not clear for the procedure.

• The "steps" in this PR summary probably can be in some readme in db so the developers have idea how to follow to run manual scripts.

These scripts assist with the standard upgrade procedure for postgres, which is to export from the old and import to the new. Feel free to create docs or link to something appropriate.

• Are the shell scripts required for elevated access to OpenShift to execute them?

OpenShift admin rights are assumed. We can try with less.

• Not clear how it can be rollback if error happens? Or pointing back to old pvc/deployment?

There are two separate databases. If the new one is unacceptable we delete it and give the old database it's name back. PR merge only happens after successful migrations.

• Is it ok if we can test this in PR (dev) environment first, by: testing from v13 -> v16 -> dummy trigger (regular) deployment (within pr) -> then v17 (just to be safe to see the process works)?

There will be no triggers, because this is a manual process. Running a demo in PR is a lot safer than TEST or PROD, so of course we can do that!

[MCatherine1994]

Hi @ianliuwk1019 @DerekRoberts, I added a Readme file to capture the process and steps we walked through together today. Feel free to take a look! Thanks!