RHIDP-11271: fixing 404 error after cached dynamic plugins config change#1786
RHIDP-11271: fixing 404 error after cached dynamic plugins config change#1786deerskindoll wants to merge 6 commits intoredhat-developer:mainfrom
Conversation
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
|
Updated preview: https://redhat-developer.github.io/red-hat-developers-documentation-rhdh/pr-1786/ @ 02/23/26 12:51:52 |
deerskindoll
added
Peer review needed 📖
Technical review done ⛅
modules/dynamic-plugins/proc-fix-404-after-cached-dynamic-plugins-config-change.adoc
Show resolved
Hide resolved
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
deerskindoll
changed the title
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
|
/cherry-pick release-1.9 |
|
@deerskindoll: once the present PR merges, I will cherry-pick it on top of DetailsIn 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. |
| kind: StatefulSet | ||
| patch: | ||
| spec: | ||
| replicas: 2 |
There was a problem hiding this comment.
I think it might be worth calling out the following for awareness:
- The default kind for RHDH is
Deployment, so after switching an existing CR to StatefulSet, the user will need to manually remove the previous Deployment that was created by the Operator. Otherwise, they will have both Deployment and StatefulSet running - Using a StatefulSet with a single replica might introduce some downtime when the pod needs to be updated, as the previous pod will need to be deleted first before the new one is recreated.
There was a problem hiding this comment.
I can add removing Deployment as a step in the procedure and add a note about the downtime. would that make sense?
deerskindoll
temporarily deployed
to
internal
GitHub Actions
Inactive
|
| requests: | ||
| storage: 1Gi | ||
| ---- | ||
| . Remove the default `kind: Deployment` from the Backstage CR |
There was a problem hiding this comment.
I mean, if users are updating an existing Backstage CR (that did not previously have this new spec.deployment.kind field set, or had it set to Deployment) by switching to StatefulSet, they would need to manually delete the previous Deployment resource that was created by the RHDH Operator. They would need to actually remove this Deployment resource from the cluster, not the Backstage CR.
This is because the Operator would now be managing a StatefulSet resource in the cluster. So the previous Deployment would remain orphan. Worse, traffic may still be sent to the previous Deployment pods.
They can do so by running this command for example, after the CR is reconciled (to avoid potential downtime):
oc delete deployment -l 'app.kubernetes.io/instance=<CR_NAME>'
Hope that clarifies.
There was a problem hiding this comment.
Actually, you can generalize this: whenever the spec.deployment.kind is changed in the CR (from Deployment to StatefulSet or vice-versa), users would need to explicitly remove the previous left-over resources from the Cluster.
If they change this field from Deployment to StatefulSet, they would need to delete the previous Deployment resource from the cluster.
If they change this field from StatefulSet to Deployment, they would need to delete the previous StatefulSet resource from the cluster.
I'll file a JIRA for the Install team to track this.
There was a problem hiding this comment.
5 participants
IMPORTANT: Do Not Merge - To be merged by Docs Team Only
Version(s):
main, release-1.9
Issue:
https://issues.redhat.com/browse/RHIDP-11271
Preview:
https://redhat-developer.github.io/red-hat-developers-documentation-rhdh/pr-1786/configuring/#fix-404-after-cached-dynamic-plugins-config-change_configuring-and-operating