Document how Keycloak is upgraded when Operator is upgraded via OLM #38297
Conversation
| * When using the default {project_name} image, the Operator by default uses a matching image of the corresponding {project_name} version, resulting in *unintended {project_name} upgrades* when the Operator is upgraded. | ||
| * Even when using custom images, major Operator upgrades can introduce compatibility issues with your existing Keycloak CR configuration. |
There was a problem hiding this comment.
Ideally it's only on major releases. There could be a word of caution on minor releases as well because of operator logic changes.
| *Potential risks:* | ||
| * Unexpected downtime during automatic upgrades | ||
| * Database schema migrations that cannot be easily rolled back |
There was a problem hiding this comment.
In particular based upon recent issues, you cannot even reliably simply roll back micro version changes - that is once 26.x.n is applied, if you want to go back to 26.x.(n -1) then you need to restore from a database snapshot, rather than just going back 1 micro in operator / keycloak versions.
| 1. Schedule maintenance windows for upgrades | ||
| 2. Test upgrades in a non-production environment first | ||
| 3. Prepare rollback plans in case of issues |
There was a problem hiding this comment.
May need to elaborate here - or at least link to the general recommendations on changing versions, which mention backing up the database.
There was a problem hiding this comment.
We do not have specific backup instructions in the upgrading guide. Still, we might improve the wording, something like:
| 3. Prepare rollback plans in case of issues | |
| 3. Back up the database to allow downgrading to the previous {project_version} in case of issues |
There was a problem hiding this comment.
@shawkins do you have specific section/guide to link here in mind?
| *Potential risks:* | ||
| * Unexpected downtime during automatic upgrades | ||
| * Database schema migrations that cannot be easily rolled back |
| 1. Schedule maintenance windows for upgrades | ||
| 2. Test upgrades in a non-production environment first | ||
| 3. Prepare rollback plans in case of issues |
There was a problem hiding this comment.
We do not have specific backup instructions in the upgrading guide. Still, we might improve the wording, something like:
| 3. Prepare rollback plans in case of issues | |
| 3. Back up the database to allow downgrading to the previous {project_version} in case of issues |
0ea1ef2 to
2317ca0
Compare
Closes: keycloak#35901 Signed-off-by: Peter Zaoral <[email protected]>
Looks good to me. It makes me wonder in general how this should be done - will we eventually need some mechanism for pre / post / rollback update hooks - something like additional images the user could specify in the CR where they could handle the database snapshot / restoration if needed. |
Closes: #35901