🌱 Enforce skip upgrade policy in clusterctl #12017
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
k8s-ci-robot
added
the
size/L
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: 5a4217b0e48fcd6f5202d4709cbb271b9c18febe
|
| return errors.Wrapf(err, "failed to parse next version for %s provider", upgradeItem.InstanceName()) | ||
| } | ||
|
|
||
| if nextVersion.Minor >= currentVersion.Minor+3 { |
There was a problem hiding this comment.
| if nextVersion.Minor >= currentVersion.Minor+3 { | |
| if nextVersion.Minor > currentVersion.Minor+3 { |
Current code would block a n-3 => n upgrade which we want to support
There was a problem hiding this comment.
Please also adjust unit test coverage accordingly (i.e. it should cover that n-3 => n is allowed)
|
Feel free to cherry-pick if desired once findings are addressed |
k8s-ci-robot
removed
the
lgtm
fabriziopandini
added
the
tide/merge-method-squash
|
Lgtm pending test coverage, xref: #12017 (comment) |
|
Took a closer look, would be too much effort to add additional test coverage there. We'll eventually have the test coverage in e2e tests /lgtm |
k8s-ci-robot
added
the
lgtm
|
LGTM label has been added. Git tree hash: b7f812e488012e8e976eda9095dec91bf8c84c83
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbueringer 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 |
k8s-ci-robot
added
the
approved
What this PR does / why we need it:
We recently improved CAPI version support policies clarifying that we support only n-3 skip upgrades, and we are now using this assumption as a cornerstone to plan API removal activities in #11919 and #11920
However, I noticed that in the clusterctl upgrade doc we were stating something slightly different, so I removed this inconsistency, but then I started thinking about the fact that clusterctl can help users preventing issue.
So I extended a little bit this PR adding a first version of skip upgrade policy check.
For now this check is hardcoded and limited to core CAPI and providers in the core repo; if there is interest we can consider extending the clustectl contract so any provider can declare it's own skip upgrade rules and enforce them via clusterctl
/area clusterctl