[release-4.21] OCPBUGS-104586: e2e: fix: clear hugepages before switching kernelPageSize to 4k

[openshift-cherrypick-robot]

This is an automated cherry-pick of #1554

/assign oblau

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d91e0eeb-5dd3-4b6a-af4e-f3e364aae6c7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[openshift-ci-robot]

@openshift-cherrypick-robot: Jira Issue OCPBUGS-92011 has been cloned as Jira Issue OCPBUGS-104586. Will retitle bug to link to clone.
/retitle [release-4.21] OCPBUGS-104586: e2e: fix: clear hugepages before switching kernelPageSize to 4k

Details

In response to this:

This is an automated cherry-pick of #1554

/assign oblau

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 openshift-eng/jira-lifecycle-plugin repository.

[qodo-for-rh-openshift]

PR Summary by Qodo

e2e: clear hugepages before enforcing 4k kernelPageSize on ARM

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Ensure ARM kernelPageSize tests start from a valid baseline (4k pages, no hugepages, RT off).
• Refactor repeated “update profile + wait for rollout” steps into a shared helper.
• Simplify profile revert logic and improve assertion diagnostics.

Diagram

graph TD
T["kernelpagesize.go (e2e)"] --> H["ApplyProfileAndWait"] --> U["profiles.UpdateWithRetry"] --> P["PerformanceProfile CR"] --> R["MCP/NodePool rollout"] --> N["Worker RT node"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Create a dedicated temporary PerformanceProfile for this suite

• ➕ Avoids mutating the cluster’s shared/default profile during the test run
• ➕ Reduces risk of interfering with other concurrently running suites
• ➖ Significantly more setup/teardown complexity and longer e2e runtime
• ➖ Requires additional labeling/selection logic and cleanup robustness

2. Only clear hugepages when switching to 4k (conditional baseline)

• ➕ Minimizes disruptive spec changes when the cluster is already in the desired state
• ➕ Reduces churn in MCP/nodepool rollouts
• ➖ More branching logic in the test; harder to reason about baseline
• ➖ Still needs careful revert behavior on partial failures

3. Patch only the specific fields (merge patch) instead of updating full objects

• ➕ Smaller API surface area for the change; avoids accidental spec drift
• ➕ Can be more resilient to unrelated spec fields changing during long e2e runs
• ➖ Adds patch construction complexity and can reduce readability
• ➖ Still requires the same rollout/wait orchestration

Recommendation: The PR’s approach (declare an explicit safe baseline and gate the update via DeepEqual, then reuse a single ApplyProfileAndWait helper) is the best tradeoff for stability and readability. It directly prevents the ARM-specific webhook rejection by clearing hugepages before enforcing 4k, while keeping changes localized and ensuring predictable cleanup.

Files changed (2) +26 / -51

Refactor (1) +14 / -0

profile_update.goAdd ApplyProfileAndWait helper for profile update + rollout completion +14/-0

Add ApplyProfileAndWait helper for profile update + rollout completion

• Introduces ApplyProfileAndWait to centralize the common pattern of updating a PerformanceProfile and waiting for MCP/nodepool rollout start and completion. Uses poolname to provide clearer progress messages during waits.

test/e2e/performanceprofile/functests/utils/profilesupdate/profile_update.go

Tests (1) +12 / -51

kernelpagesize.goStabilize ARM kernelPageSize e2e by enforcing a safe baseline and cleanup +12/-51

Stabilize ARM kernelPageSize e2e by enforcing a safe baseline and cleanup

• Updates the suite to start from a declarative baseline (kernelPageSize=4k, hugepages cleared, RT disabled) to avoid webhook rejections on ARM clusters. Replaces inline update/wait sequences with the shared ApplyProfileAndWait helper and simplifies revert logic by comparing specs directly. Improves assertion messaging for node page-size verification.

test/e2e/performanceprofile/functests/14_arm/kernelpagesize.go

[openshift-ci-robot]

@openshift-cherrypick-robot: This pull request references Jira Issue OCPBUGS-104586, which is invalid:

• expected dependent Jira Issue OCPBUGS-92011 to be in one of the following states: VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA), but it is ON_QA instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

This is an automated cherry-pick of #1554

/assign oblau

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 openshift-eng/jira-lifecycle-plugin repository.

[qodo-for-rh-openshift]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Waits on no-op update 🐞 Bug ☼ Reliability

Description

BeforeAll forces default-equivalent spec fields (e.g., KernelPageSize=4k,
RealTimeKernel.Enabled=false, HugePages=nil) and then may call ApplyProfileAndWait whenever the raw
Spec differs from the original, even if the rendered MachineConfig would be unchanged. In that case
WaitForTuningUpdating can wait until mcps.WaitForCondition times out (40 min/node) because the MCP
may never enter Updating=True.

Code

test/e2e/performanceprofile/functests/14_arm/kernelpagesize.go[R60-63]

+		perfProfile.Spec.HugePages = nil
+		perfProfile.Spec.KernelPageSize = ptr.To(performancev2.KernelPageSize(kernelPageSize4k))
+		perfProfile.Spec.RealTimeKernel = &performancev2.RealTimeKernel{
+			Enabled: ptr.To(false),

Relevance

●● Moderate

Reliability concern is plausible, but skipping waits on rendered no-op updates needs nuanced rollout
detection.

PR-#1550
PR-#1556

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The test updates the PerformanceProfile to explicit default values and then uses a helper that
always waits for MCP/nodepool rollout. The operator code treats KernelPageSize=nil as default 4k and
only changes kernel type for RT enabled=true or KernelPageSize=64k, so explicit 4k / RT disabled can
be a rendered no-op. When no rollout occurs, WaitForTuningUpdating relies on mcps.WaitForCondition
which can take 40 minutes per node before timing out.

test/e2e/performanceprofile/functests/14_arm/kernelpagesize.go[59-68]
test/e2e/performanceprofile/functests/utils/profilesupdate/profile_update.go[87-120]
test/e2e/performanceprofile/functests/utils/profilesupdate/profile_update.go[133-144]
test/e2e/performanceprofile/functests/utils/mcps/mcps.go[32-34]
test/e2e/performanceprofile/functests/utils/mcps/mcps.go[190-199]
pkg/apis/performanceprofile/v2/performanceprofile_validation.go[397-404]
pkg/performanceprofile/controller/performanceprofile/components/machineconfig/machineconfig.go[153-168]
pkg/apis/performanceprofile/v2/performanceprofile_types.go[77-82]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`kernelpagesize.go` normalizes the PerformanceProfile by setting default-equivalent fields (KernelPageSize=4k, RealTimeKernel.Enabled=false, HugePages=nil) and then calls `profilesupdate.ApplyProfileAndWait(...)` based on a raw `Spec` DeepEqual comparison. Some of these raw-spec changes can be semantically no-ops for rendered node configuration (e.g., KernelPageSize defaults to 4k when unset; RT is disabled when RealTimeKernel is nil), so no MCP rollout may start and the test can block until the MCP wait times out.

### Issue Context
- `ApplyProfileAndWait` always waits for the tuning update to start and complete.
- `mcps.WaitForCondition` uses a large timeout (40 minutes per targeted node).

### Fix Focus Areas
- test/e2e/performanceprofile/functests/14_arm/kernelpagesize.go[59-68]
- test/e2e/performanceprofile/functests/utils/profilesupdate/profile_update.go[133-144]

### Suggested fix approaches
Pick one:
1) **Only mutate/apply fields that actually require a rollout**:
  - Don’t force `RealTimeKernel` from `nil` to `{Enabled:false}`; only disable it if it is explicitly enabled.
  - Don’t force `KernelPageSize` to explicit `4k` unless it is explicitly `64k` (or you detect the node is currently 64k).
  - Keep clearing `HugePages` (the PR’s intent) but only call `ApplyProfileAndWait` if `HugePages` was non-nil / non-empty or other truly roll-out-affecting fields changed.

2) **Make `ApplyProfileAndWait` tolerant to no-rollout updates**:
  - Capture MCP/nodepool “update state” (e.g., current generation / config source / Updating status) before update.
  - After `UpdateWithRetry`, if the pool never transitions into Updating within a short window, skip the rollout wait and proceed (or assert expected state directly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[qodo-for-rh-openshift]

1. Waits on no-op update 🐞 Bug ☼ Reliability

BeforeAll forces default-equivalent spec fields (e.g., KernelPageSize=4k,
RealTimeKernel.Enabled=false, HugePages=nil) and then may call ApplyProfileAndWait whenever the raw
Spec differs from the original, even if the rendered MachineConfig would be unchanged. In that case
WaitForTuningUpdating can wait until mcps.WaitForCondition times out (40 min/node) because the MCP
may never enter Updating=True.

Agent Prompt

### Issue description
`kernelpagesize.go` normalizes the PerformanceProfile by setting default-equivalent fields (KernelPageSize=4k, RealTimeKernel.Enabled=false, HugePages=nil) and then calls `profilesupdate.ApplyProfileAndWait(...)` based on a raw `Spec` DeepEqual comparison. Some of these raw-spec changes can be semantically no-ops for rendered node configuration (e.g., KernelPageSize defaults to 4k when unset; RT is disabled when RealTimeKernel is nil), so no MCP rollout may start and the test can block until the MCP wait times out.

### Issue Context
- `ApplyProfileAndWait` always waits for the tuning update to start and complete.
- `mcps.WaitForCondition` uses a large timeout (40 minutes per targeted node).

### Fix Focus Areas
- test/e2e/performanceprofile/functests/14_arm/kernelpagesize.go[59-68]
- test/e2e/performanceprofile/functests/utils/profilesupdate/profile_update.go[133-144]

### Suggested fix approaches
Pick one:
1) **Only mutate/apply fields that actually require a rollout**:
   - Don’t force `RealTimeKernel` from `nil` to `{Enabled:false}`; only disable it if it is explicitly enabled.
   - Don’t force `KernelPageSize` to explicit `4k` unless it is explicitly `64k` (or you detect the node is currently 64k).
   - Keep clearing `HugePages` (the PR’s intent) but only call `ApplyProfileAndWait` if `HugePages` was non-nil / non-empty or other truly roll-out-affecting fields changed.

2) **Make `ApplyProfileAndWait` tolerant to no-rollout updates**:
   - Capture MCP/nodepool “update state” (e.g., current generation / config source / Updating status) before update.
   - After `UpdateWithRetry`, if the pool never transitions into Updating within a short window, skip the rollout wait and proceed (or assert expected state directly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: openshift-cherrypick-robot
Once this PR has been reviewed and has the lgtm label, please assign yanirq for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@openshift-cherrypick-robot: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

[oblau]

/jira refresh

[openshift-ci-robot]

@oblau: This pull request references Jira Issue OCPBUGS-104586, which is valid. The bug has been moved to the POST state.

7 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.21.z) matches configured target version for branch (4.21.z)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)
• release note type set to "Release Note Not Required"
• dependent bug Jira Issue OCPBUGS-92011 is in the state Verified, which is one of the valid states (VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA))
• dependent Jira Issue OCPBUGS-92011 targets the "4.22.0" version, which is one of the valid target versions: 4.22.0
• bug has dependents

Details

In response to this:

/jira refresh

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 openshift-eng/jira-lifecycle-plugin repository.