-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Clusterctl should enforce provider order during init and upgrade #5327
Comments
@fabriziopandini: Closing this issue. 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/test-infra repository. |
/milestone v1.0 |
/kind release-blocking |
Some additional context: We actually also had this issue with CAPD, but it just never surfaced. In case of CAPD, the CAPD controller was upgraded and then all others and it recovered automatically after the other providers have been deployed. The difference in CAPA was that CAPA has a cluster-wide resource called So what did actually happen in the CAPA upgrade case:
|
Detailed Description
While testing clusterctl v1alpha3-->v1alpha4 upgrade we detected flakiness due to clusterctl upgrade upgrading a provider before than upgrading CAPI.
The web hook failure was caused by the provider controller trying to use version of core types not yet installed due to the upgrade order.
This error was not being detected in the CAPI test grid by chance, because without an explicit order being enforced, the order returned by List provider was being applied.
While investigating this issue, we also identified some problems in CAPA E2E, now being addressed.
However it should be great to have some more coverage on provider as well, which is something we will get for CAPA, CAPV, CAPZ as part of v1beta1 activities..
Anything else you would like to add:
A way to recover from this problem is to manually apply core-provider manifests for CAPI/target version and then restart upgrades.
The fix merged in main and it was already back ported in release-0.4 branch; this will require a release ASAP
/kind bug
The text was updated successfully, but these errors were encountered: