-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement support for respecting upgrade graph semantics #54
Comments
cc @joelanford in case you have any thoughts on those open questions. It seems like having runtime checks in rukpak's plain bundle format would be needed here to avoid blasting through the defined upgrade graph semantics to avoid the following scenario:
Any implementation that simply looks at the replaces chain here would pivot to v0.2.0 once it's available, then the controller would catch the BD event and requeue, and then select the v0.3.0 as it's the highest semver available and there's no logic that can inspect the state of something like a deployment. |
We'll also need to be able to delineate between "my operator cannot be upgraded right now as performing migration logic" and "my operator was able to successfully be applied to the cluster but it's failing at runtime" to have a more robust story about upgrades that doesn't exist in the current implementation. |
I imagine this will be in scope for an integration with deppy, where the operator controller has a way to tell deppy:
|
Goal: Ensure the defined upgrade graph semantics are respected during upgrades. The current implementation always chooses the highest semver bundle in the desired package name without inspecting the upgrade graph semantics.
Needs Clarification on Scope:
Open Questions:
The text was updated successfully, but these errors were encountered: