proposal: Postgres Operator Upgrade #23
Conversation
| ## Summary | ||
|
|
||
| This enhancement proposes upgrading the version of Postgres on the Red Hat Kubernetes Operator | ||
| from version 10 to version 14. Due to the EOL of Postgres 10, the upgrade is critical. |
There was a problem hiding this comment.
I'm curious, why not go directly to Postgres 15?
|
|
||
| The largest risk involved is that of data loss. In order to mitigate this, the backup job must be | ||
| completed in order for the upgrade process to happen. After the upgrade, the Operator will point | ||
| to the NEW PVC, meaning the clients original data is never touched. This old PVC can be left on |
There was a problem hiding this comment.
What storage requirements should we list for v3.9.0?
| off. | ||
| 2. The reconciler checks the postgres image tag, and determines the current postgres version being | ||
| used. | ||
| 3. If the postgres version is inspected from the tag and if an upgrade is determined necessary, |
There was a problem hiding this comment.
How will it determine when an upgrade is necessary and ready?
| 3. If the postgres version is inspected from the tag and if an upgrade is determined necessary, | ||
| the following events will be triggered. | ||
|
|
||
| 4. A Kubernetes Job object definition is created include the commands to run a postgres backup before the postgres upgrade. |
There was a problem hiding this comment.
How long can we expect the backup to take and will it require downtime?
| 5. An additional PVC in which the data will be backed up. | ||
| 6. Retrigger reconcile loop | ||
| 7. A Kubernetes Job object definition is created include the commands to run a postgres upgrade. | ||
| 8. Retrigger reconcile loop |
There was a problem hiding this comment.
Will there need to be a restart of the Quay pod after the upgrade completes?
| ### Upgrade / Downgrade Strategy | ||
|
|
||
| This is an open question to be discuessed. | ||
| Should downgrades be supported? (this is separate from a revert due to failure) |
There was a problem hiding this comment.
I don't think I've ever heard of DB downgrades in production. @kwestpharedhat can chime in, but I'd be wary of reverting a DB upgrade.
|
Should we give users the option of deleting the backup? How long should it persist? |
|
Will this process be identical for the Clair DB? |
|
|
||
| ### Non-Goals | ||
|
|
||
| Database Backup and Restore (as a feature) / This should be a separate enhancement |
There was a problem hiding this comment.
Backup is a goal and a non-goal at the same time.
Do you want to create backups and provide instructions to how use them manually?
| the following events will be triggered. | ||
|
|
||
| 4. A Kubernetes Job object definition is created include the commands to run a postgres backup before the postgres upgrade. | ||
| 5. An additional PVC in which the data will be backed up. |
There was a problem hiding this comment.
If the operator is killed right after this step, will it create a new PVC once it is back again?
| 4. A Kubernetes Job object definition is created include the commands to run a postgres backup before the postgres upgrade. | ||
| 5. An additional PVC in which the data will be backed up. | ||
| 6. Retrigger reconcile loop | ||
| 7. A Kubernetes Job object definition is created include the commands to run a postgres upgrade. |
There was a problem hiding this comment.
As operators shouldn't be imperative, but declarative, how would you describe (check for) this state, i.e. that the previous steps are done?
This enhancement proposes a method of upgrading the version of Postgres on the Red Hat Kubernetes Operator from version 10 to version 14.