Conversation
Update operator profiles, related images, generated manifests, and restricted-environment mirrors for PostgreSQL 18. Existing local database migration remains a documented manual procedure. Refs: RHIDP-13959 Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
PR Summary by QodoUpgrade default PostgreSQL to 18 with migration E2E coverage
AI Description
Diagram
High-Level Assessment
Files changed (22)
|
Code Review by Qodo
1. Existing local databases fail to start
|
| - name: PGDATA | ||
| value: /var/lib/pgsql/data/userdata | ||
| image: quay.io/fedora/postgresql-15:latest # will be replaced with the actual image | ||
| image: quay.io/fedora/postgresql-18:latest # will be replaced with the actual image |
There was a problem hiding this comment.
1. Existing local databases fail to start 🐞 Bug ≡ Correctness
The generated StatefulSet’s default image changes from PostgreSQL 15 to 18, while reconciliation retains the existing data PVC and provides no major-version migration path. When an Operator managing an existing PostgreSQL 15 local database is upgraded, PostgreSQL 18 starts against the PostgreSQL 15 data directory, disrupting database startup and Backstage availability until an administrator manually dumps, replaces the volume, and restores the database.
Agent Prompt
## Issue description
Changing the default local PostgreSQL image from 15 to 18 causes existing generated StatefulSets to roll onto PostgreSQL 18 while retaining their PostgreSQL 15 PVC, even though the tested migration procedure requires a logical dump, volume replacement, and restore. Add an explicit safe migration path or prevent this unsupported in-place major upgrade, while keeping PostgreSQL 18 as the default for newly created instances and documenting the administrator procedure.
## Fix Focus Areas
- config/profile/rhdh/default-config/db-statefulset.yaml[33-36]
- pkg/model/db-statefulset.go[42-67]
- pkg/model/db-statefulset.go[76-101]
- internal/controller/backstage_controller.go[143-176]
- tests/e2e/postgresql_upgrade_test.go[83-106]
## Recommended Fix
Before applying a major-version image change to an existing local PostgreSQL StatefulSet, detect its existing database version or image and prevent reconciliation from applying PostgreSQL 18 while it remains backed by a PostgreSQL 15 volume. Either retain PostgreSQL 15 for existing instances until an explicit migration action confirms that the volume has been replaced, or implement an opt-in operator-managed flow that exports the PostgreSQL 15 data, deletes and replaces the StatefulSet and PVC, provisions PostgreSQL 18 with a fresh volume, restores the dump, and refreshes collations. Document this supported migration procedure in the product documentation, and continue using PostgreSQL 18 by default only for newly created instances.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
|
Important The |
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
Assisted-by: OpenCode Signed-off-by: Zbyněk Drápela <zbynek.drapela@gmail.com>
|
There was a problem hiding this comment.
Do we really need this unit test testing a helper defined in the E2E suite? captureOperatorLogsBeforeCleanup is a 3 lines function..
There was a problem hiding this comment.
Same for this btw. This unit test file doesn't seem necessary IMO.
There was a problem hiding this comment.
Do we really need this on every PR? Maybe just the nightly upgrade workflow above is enough? We could maybe just limit it for now to the release-1.10 => main upgrade path today (and later include 1.10 => release-2.1 too)?



Summary
This upgrade path was tested with the full E2E test suite in redhat-developer/rhdh#5145
Verification
make lintmake test OPERATOR_DP_PROCESSING=falseactionlintfor the new pull-request workflowJira: https://redhat.atlassian.net/browse/RHIDP-13959