Allow node pool major upgrades#4479
Merged
openshift-merge-bot[bot] merged 1 commit intomainfrom Apr 17, 2026
Merged
Conversation
machi1990
reviewed
Mar 16, 2026
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
ec4e739 to
6b0d466
Compare
machi1990
reviewed
Mar 16, 2026
machi1990
reviewed
Mar 16, 2026
machi1990
reviewed
Mar 16, 2026
deads2k
reviewed
Mar 17, 2026
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 21, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 21, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 21, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 23, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 23, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
machi1990
added a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 23, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 24, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
that referenced
this pull request
Mar 25, 2026
…nodepool creation While working on #4505 and further reviewing of #4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once #4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 25, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 25, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 26, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 27, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 30, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
6b0d466 to
c5a281c
Compare
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
2 times, most recently
from
7231c62 to
d49bc32
Compare
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Mar 31, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
281317e to
c8c060f
Compare
geoberle
reviewed
Apr 9, 2026
|
|
||
| // Validate the customer's desired version before setting it | ||
| if err := c.validateDesiredNodePoolVersion(ctx, &customerDesiredVersion, existingServiceProviderNodePool, existingServiceProviderCluster, nodePool.Properties.Version.ChannelGroup, clusterKey, clusterUUID); err != nil { | ||
| if err := c.validateDesiredNodePoolVersion(ctx, &customerDesiredVersion, existingServiceProviderNodePool, existingServiceProviderCluster, subscription, nodePool.Properties.Version.ChannelGroup, clusterKey, clusterUUID); err != nil { |
Collaborator
There was a problem hiding this comment.
normalization
something like this like we do in the frontend?
operation.Operation{
Options: validation.AFECsToValidationOptions(subscription.GetRegisteredFeatures()),
}.HasOption(api.FeatureExperimentalReleaseFeatures)
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
0a9debb to
5ad7780
Compare
JameelB
reviewed
Apr 10, 2026
Collaborator
|
lgtm, still see comments that's not yet resolved, ptal when you get a chance @geoberle 🙏 |
machi1990
reviewed
Apr 13, 2026
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Apr 13, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
2 times, most recently
from
8f45f3f to
fadc3ec
Compare
machi1990
reviewed
Apr 15, 2026
machi1990
reviewed
Apr 15, 2026
machi1990
reviewed
Apr 15, 2026
machi1990
reviewed
Apr 15, 2026
machi1990
reviewed
Apr 15, 2026
Collaborator
|
left minor suggestions, otherwise lgtm |
cgiradkar
pushed a commit
to machi1990/ARO-HCP
that referenced
this pull request
Apr 15, 2026
…nodepool creation While working on Azure#4505 and further reviewing of Azure#4554 I realised that the frontend was missing skew validation while creating the node pool. The PR adds the skew validation by performing the following rules: - if the version is set - validate that node pool desired minor version is within the maximum of 2 minors lower skew and not higher than the control plane minor - validate that the desired node pool version isn't higher that the lowest active control plane version if this is available: only available post install - validate that when control plane major != nodepool major version then only valid skews are allowed - for now the definition of valid skew is: if cp on 5.0 then the node pool can be on 4.21 or 4.22 if cp is on 5.1 then the node pool can be on 4.21, 4.22 or 4.23 if cp is on 5.2 then the node pool can be only on 4.23 I left a TODO to put this behind an AFEC flag once Azure#4479 is merged and it'll done as a followup - if the lowest control plane version is available and node pool version set, perform the same minor skew as done for the cluster desired version but using the actual cluster version minor The change also introduces some defaulting logic in case version isn't set: in this case we default to the lowest active control plane version.
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
fadc3ec to
37673ef
Compare
|
@ahitacat: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
machi1990
reviewed
Apr 17, 2026
Collaborator
machi1990
left a comment
machi1990
left a comment
There was a problem hiding this comment.
Once the unit test pass the change looks good to me
Use the subscription AFEC flag experimental feature to allow major upgrades. This is used in both the frontend and the controller that calculates the desiredVersion. Refactors the node pool upgrade validations so they can be shared by frontend and backend. Refactor apihelpers functions and shared variables. Signed-off-by: Alba Hita Catala <ahitacat@redhat.com>
ahitacat
force-pushed
the
ahitacat/allow-major-upgrades
branch
from
37673ef to
6b3f6db
Compare
Collaborator
|
/lgtm |
Collaborator
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahitacat, geoberle, machi1990 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Create a new feature tag AllowMajorUpgrades that will allow node pool major upgrades. This PR only adds support to allow the change. However, cluster .y and .x upgrades are not yet in place, and CS requires more changes to this upgrade be complete.
Why
Adding initial support for node pools major upgrades, to start working on this feature sooner.
Special notes for your reviewer
Refactors and tests in different commits, once it is approved/lgtm I will squash them. Addressing also some related comments from #4720 and #4566