-
Notifications
You must be signed in to change notification settings - Fork 15
fix: Make sure to use backward-compatible names for resources created by the operator [RHIDP-2432] #369
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not like to have different name patterns for generated objects forever, let's unify it sooner than later.
ec43e69
to
efe463e
Compare
efe463e
to
4ac5a97
Compare
@rm3l: once the present PR merges, I will cherry-pick it on top of 1.2.x in a new PR and assign it to you. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Otherwise, when upgrading from 1.1, a new StatefulSet would be created with a new data PVC, causing the application to boot with from a brand new database. This would break the upgrade path.
This generalizes the previous commit, as I realized that, otherwise, we might actually be creating duplicate resources like app-config ConfigMaps/Secrets/Services with different names (while keeping the existing ones), which might confuse people upgrading from 1.1. This makes sure we avoid such a similar situation in the future by ensuring naming is done in a backward-compatible manner.
Some resources like StatefulSets allow patching a limited set of fields. For cases where we are upgrading existing instances, we might need to change the StatefulSet spec. The recommended approach to doing this is to delete the existing StatefulSet, but keep its dependents (like PVCs and Pods) orphan, then recreate the StatefulSet. This way, it will be upgraded (with some downtime) with no data loss.
This reverts commit 0b1be1c2720d96dd6bdd60f230e66819b2bc9e4b.
Co-authored-by: Gennady Azarenkov <[email protected]>
Co-authored-by: Gennady Azarenkov <[email protected]>
e8cba22
to
604b7ed
Compare
Quality Gate passedIssues Measures |
/hold cancel Rebased onto |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gazarenkov The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@rm3l: new pull request created: #377 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Description
This fixes a critical issue where, when upgrading existing resources using an operator upgraded from 1.1 to 1.2 (
main
branch), the operator would create and use a brand new database StatefulSet. This would cause the upgraded Backstage application to boot using an empty database, rather than starting with the existing database (which could already contain some data).It also fixes a more general issue where resource naming was not backward-compatible, which would create for example 2 different ConfigMaps after an upgrade: one namedbackstage-dynamic-plugins-<cr>
(created by the operator on themain
branch) besides an already existing one named<cr>-dynamic-plugins
(created in 1.1), which could create some confusion when looking at the resources in the namespace.Which issue(s) does this PR fix or relate to
PR acceptance criteria
rhdh-operator.csv.yaml
file accordinglyHow to test changes / Special notes to the reviewer
See the repro steps depicted in https://issues.redhat.com/browse/RHIDP-2432 and run the tests with the following command: