Skip to content

ROSAENG-132: fix(karpenter): Set Ready condition to False when version resolution fails#7866

Merged
openshift-merge-bot[bot] merged 1 commit intoopenshift:mainfrom
joshbranham:joshbranham/set-ready-false-on-version-resolution-failure
Mar 10, 2026
Merged

ROSAENG-132: fix(karpenter): Set Ready condition to False when version resolution fails#7866
openshift-merge-bot[bot] merged 1 commit intoopenshift:mainfrom
joshbranham:joshbranham/set-ready-false-on-version-resolution-failure

Conversation

@joshbranham
Copy link
Copy Markdown
Contributor

@joshbranham joshbranham commented Mar 5, 2026

What this PR does / why we need it:

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
    • Added a top-level Ready condition to indicate node class readiness, derived from version resolution and underlying readiness.
  • Bug Fixes
    • Ready is now set to False when version resolution fails, preventing use of unresolved configurations and centralizing Ready semantics.
  • Tests
    • New unit tests covering Ready computation across resolved, unresolved, unknown, and missing version scenarios.
  • Chores
    • Minor formatting tidy-ups.

@openshift-ci-robot
Copy link
Copy Markdown

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 5, 2026
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 5, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

When an OpenshiftEC2NodeClass has a spec.version that fails validation or Cincinnati resolution, the VersionResolved condition was set to False but the top-level Ready condition was left unchanged. This meant kubectl get oec2nc could still show Ready=True despite having an invalid version configuration.

Update updateVersionStatus to also set Ready=False with reason ResolutionFailed when resolveErr is non-nil, covering both validateVersion and resolveReleaseImage failure paths.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

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.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Mar 5, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro

Run ID: 8449a676-8487-4bea-826b-a256fc36f913

📥 Commits

Reviewing files that changed from the base of the PR and between 7e9e260 and 090e738.

⛔ Files ignored due to path filters (1)
  • vendor/github.com/openshift/hypershift/api/karpenter/v1beta1/karpenter_types.go is excluded by !**/vendor/**, !vendor/**
📒 Files selected for processing (5)
  • api/karpenter/v1beta1/karpenter_types.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go
  • karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller.go
  • karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go
🚧 Files skipped from review as they are similar to previous changes (2)
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go
  • karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go

Walkthrough

Adds a new exported readiness constant and implements atomic Ready condition computation for OpenshiftEC2NodeClass in the EC2 nodeclass reconciler; includes unit tests for computeReadyCondition and minor whitespace adjustments in the ignition controller files.

Changes

Cohort / File(s) Summary
API Types
api/karpenter/v1beta1/karpenter_types.go
Added exported constant ConditionTypeReady = "Ready" (top-level readiness condition).
EC2 NodeClass Controller
karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller.go
Added computeReadyCondition method and invoke during status reconciliation to compute/set the top-level Ready condition based on VersionResolved and existing EC2 readiness.
EC2 NodeClass Tests
karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go
Added TestComputeReadyCondition (covers VersionResolved=false, true, absent, unknown) and a findCondition test helper.
Ignition Controller (whitespace)
karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go, karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go
Non-functional formatting: added blank line(s) around VersionResolved-related assertion/SetStatusCondition; no behavior changes.

Sequence Diagram(s)

sequenceDiagram
    participant Reconciler as EC2NodeClassReconciler
    participant Resource as OpenshiftEC2NodeClass
    participant Status as StatusPatch/Setter
    participant K8sAPI as Kubernetes API

    Reconciler->>Resource: fetch current status.conditions
    Reconciler->>Reconciler: computeReadyCondition(VersionResolved, EC2Readiness)
    alt VersionResolved == False
        Reconciler->>Status: set Ready = False, Reason = VersionResolvedFailed
    else VersionResolved == True or absent
        Reconciler->>Status: preserve or set Ready based on EC2 readiness
    end
    Status->>K8sAPI: patch status with updated Ready condition
    K8sAPI-->>Status: status patch response
    Status-->>Reconciler: updated status acknowledged
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Test Structure And Quality ⚠️ Warning TestComputeReadyCondition test lacks meaningful failure messages in Expect assertions for readyCond, Status, and Reason validations. Add meaningful failure messages to all Expect assertions (e.g., g.Expect(readyCond).NotTo(BeNil(), "Ready condition should be computed from VersionResolved status"))
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding logic to set the Ready condition to False when version resolution fails, which aligns with the primary objective of computing Ready atomically by combining EC2 readiness with VersionResolved status.
Stable And Deterministic Test Names ✅ Passed All test names in the modified test files are stable and deterministic, using only hardcoded static strings with no dynamic information.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci openshift-ci bot requested review from enxebre and sjenning March 5, 2026 18:15
@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aws-techpreview

@openshift-ci openshift-ci bot added area/api Indicates the PR includes changes for the API area/karpenter-operator Indicates the PR includes changes related to the Karpenter operator and removed do-not-merge/needs-area labels Mar 5, 2026
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 5, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

When an OpenshiftEC2NodeClass has a spec.version that fails validation or Cincinnati resolution, the VersionResolved condition was set to False but the top-level Ready condition was left unchanged. This meant kubectl get oec2nc could still show Ready=True despite having an invalid version configuration.

Update updateVersionStatus to also set Ready=False with reason ResolutionFailed when resolveErr is non-nil, covering both validateVersion and resolveReleaseImage failure paths.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
  • Added a Ready condition to track whether node class configuration is valid and ready for operation.
  • Ready condition automatically sets to False when version resolution fails, preventing node launches with invalid configurations.

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.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go (1)

943-974: Add a recovery-path test to guard against stale Ready=False.

Please add a case that calls updateVersionStatus with resolveErr != nil first, then with success, and verifies Ready is no longer stuck on ResolutionFailed.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go`
around lines 943 - 974, Add a new test that exercises the recovery path in
updateVersionStatus: create a NodeClass (use newNodeClass like
"recover-version"), initialize a fakeGuestClient and
KarpenterIgnitionReconciler, call r.updateVersionStatus(ctx, nc, "", "",
resolveErr) with a non-nil error to set the ResolutionFailed/Ready=False state,
then call r.updateVersionStatus(ctx, nc, "quay.io/openshift/release:latest",
"4.17.0", nil) to simulate a successful resolution; fetch the updated
OpenshiftEC2NodeClass via fakeGuestClient.Get and assert that
Status.ReleaseImage is set, VersionResolved condition is metav1.ConditionTrue
(not ResolutionFailed), and the Ready condition is not stuck on Reason
"ResolutionFailed" and is set to True (or cleared of the ResolutionFailed state)
to confirm recovery.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go`:
- Around line 535-547: The current code only sets ConditionTypeReady to False
when resolveErr != nil, so a previous Ready=False with
Reason=ConditionReasonResolutionFailed can persist after a later successful
resolution; update the success path (where resolveErr == nil / after version
resolution completes) to explicitly set or replace the Ready condition to
Status=True (ObservedGeneration = openshiftEC2NodeClass.Generation,
LastTransitionTime = metav1.Now(), Reason = "" or a success reason) using
meta.SetStatusCondition on openshiftEC2NodeClass.Status.Conditions (or remove
the ResolutionFailed condition) so the Ready condition is cleared/updated when
resolution succeeds; locate resolveErr, the existing readyCondition block, and
the use of meta.SetStatusCondition to apply the fix.

---

Nitpick comments:
In
`@karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go`:
- Around line 943-974: Add a new test that exercises the recovery path in
updateVersionStatus: create a NodeClass (use newNodeClass like
"recover-version"), initialize a fakeGuestClient and
KarpenterIgnitionReconciler, call r.updateVersionStatus(ctx, nc, "", "",
resolveErr) with a non-nil error to set the ResolutionFailed/Ready=False state,
then call r.updateVersionStatus(ctx, nc, "quay.io/openshift/release:latest",
"4.17.0", nil) to simulate a successful resolution; fetch the updated
OpenshiftEC2NodeClass via fakeGuestClient.Get and assert that
Status.ReleaseImage is set, VersionResolved condition is metav1.ConditionTrue
(not ResolutionFailed), and the Ready condition is not stuck on Reason
"ResolutionFailed" and is set to True (or cleared of the ResolutionFailed state)
to confirm recovery.

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro

Run ID: f619de0b-cf1a-4fcb-b80c-1dcd7efaa41d

📥 Commits

Reviewing files that changed from the base of the PR and between 687e33e and d24b773.

⛔ Files ignored due to path filters (1)
  • vendor/github.com/openshift/hypershift/api/karpenter/v1beta1/karpenter_types.go is excluded by !**/vendor/**, !vendor/**
📒 Files selected for processing (3)
  • api/karpenter/v1beta1/karpenter_types.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go

Comment thread karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go Outdated
@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aws-techpreview

@enxebre
Copy link
Copy Markdown
Member

enxebre commented Mar 6, 2026

if we want to include ConditionReasonResolutionFailed into the upper level ready semantic, I think what ever is bubbling up the ready condition (ec2 node class controller atm) should compute that atomically, i.e. upper level ready = (ec2 ready && ConditionReasonResolutionFailed)

@joshbranham joshbranham force-pushed the joshbranham/set-ready-false-on-version-resolution-failure branch from d24b773 to 476587a Compare March 7, 2026 22:22
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 7, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
  • Added a Ready condition to track whether node class configuration is valid and ready for operation.
  • Ready condition automatically sets to False when version resolution fails, preventing node launches with invalid configurations.

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.

@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aws-techpreview

@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 7, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
  • Added a top-level Ready condition to indicate node class readiness; it is computed to reflect combined version resolution and underlying readiness.
  • Bug Fixes
  • Ready is set to False when version resolution fails, preventing launches with invalid configurations and centralizing Ready semantics.
  • Tests
  • Added unit tests covering Ready computation across version-resolved and unresolved scenarios.
  • Chores
  • Minor non-functional formatting tidy-ups.

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.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go (1)

551-638: Good test coverage for computeReadyCondition.

The test cases cover the key scenarios: VersionResolved=False overriding Ready, VersionResolved=True preserving Ready, and absent VersionResolved condition.

Minor note: The readyShouldChange field (line 557) is defined but never used in the assertions. Consider removing it or adding an assertion if the intent was to verify condition mutation behavior.

♻️ Remove unused field or add assertion
 	testCases := []struct {
 		name                string
 		conditions          []metav1.Condition
 		expectedReadyStatus metav1.ConditionStatus
 		expectedReadyReason string
-		readyShouldChange   bool
 	}{

Or alternatively, add a test that uses this field to verify transition behavior.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go`
around lines 551 - 638, The test defines an unused field readyShouldChange in
the testCases struct; remove the readyShouldChange field and any references to
it (the struct field on the anonymous test case and any related variables) to
eliminate dead test data in TestComputeReadyCondition, locating the struct
declaration in TestComputeReadyCondition and the per-case initializers that
include readyShouldChange.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go`:
- Around line 551-638: The test defines an unused field readyShouldChange in the
testCases struct; remove the readyShouldChange field and any references to it
(the struct field on the anonymous test case and any related variables) to
eliminate dead test data in TestComputeReadyCondition, locating the struct
declaration in TestComputeReadyCondition and the per-case initializers that
include readyShouldChange.

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro

Run ID: 5a2d27b5-e5dd-448c-8acf-e0de0e3f3c5f

📥 Commits

Reviewing files that changed from the base of the PR and between d24b773 and 476587a.

⛔ Files ignored due to path filters (1)
  • vendor/github.com/openshift/hypershift/api/karpenter/v1beta1/karpenter_types.go is excluded by !**/vendor/**, !vendor/**
📒 Files selected for processing (5)
  • api/karpenter/v1beta1/karpenter_types.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller.go
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go
  • karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller.go
  • karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller_test.go
✅ Files skipped from review due to trivial changes (1)
  • karpenter-operator/controllers/karpenterignition/karpenterignition_controller_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • api/karpenter/v1beta1/karpenter_types.go

@joshbranham joshbranham force-pushed the joshbranham/set-ready-false-on-version-resolution-failure branch from 476587a to 7e9e260 Compare March 7, 2026 23:32
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 7, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
  • Added a top-level Ready condition to indicate node class readiness, computed from version resolution and underlying readiness.
  • Bug Fixes
  • Ready is now set to False when version resolution fails, preventing use of unresolved configurations and centralizing Ready semantics.
  • Tests
  • New unit tests covering Ready computation across resolved, unresolved, and missing version scenarios.
  • Chores
  • Minor formatting tidy-ups.

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.

@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aws-techpreview

@joshbranham
Copy link
Copy Markdown
Contributor Author

/retest

Comment thread karpenter-operator/controllers/nodeclass/ec2_nodeclass_controller.go Outdated
…fails

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Previously the ignition controller set Ready directly, which could race
with the ec2nodeclass controller that also patches status. Moving the
computation into reconcileStatus ensures a single controller owns the
Ready semantic and both conditions are evaluated in a single status
patch.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@joshbranham joshbranham force-pushed the joshbranham/set-ready-false-on-version-resolution-failure branch from 7e9e260 to 090e738 Compare March 9, 2026 14:14
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Mar 9, 2026

@joshbranham: This pull request references ROSAENG-132 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

What this PR does / why we need it:

Compute the Ready condition atomically in the EC2 node class controller
by combining the upstream EC2NodeClass Ready status with the
VersionResolved condition. When VersionResolved is False, Ready is
overridden to False regardless of EC2 readiness.

Which issue(s) this PR fixes:

Fixes ROSAENG-132

Special notes for your reviewer:

Checklist:

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.
  • This change includes docs.
  • This change includes unit tests.

Summary by CodeRabbit

  • New Features
  • Added a top-level Ready condition to indicate node class readiness, derived from version resolution and underlying readiness.
  • Bug Fixes
  • Ready is now set to False when version resolution fails, preventing use of unresolved configurations and centralizing Ready semantics.
  • Tests
  • New unit tests covering Ready computation across resolved, unresolved, unknown, and missing version scenarios.
  • Chores
  • Minor formatting tidy-ups.

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.

@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aws-techpreview

@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-azure-self-managed

@maxcao13
Copy link
Copy Markdown
Member

maxcao13 commented Mar 9, 2026

Let's see if I can do this :-)

/approve

EDIT: guess not

@maxcao13
Copy link
Copy Markdown
Member

maxcao13 commented Mar 9, 2026

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 9, 2026
@openshift-ci-robot
Copy link
Copy Markdown

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws

@cwbotbot
Copy link
Copy Markdown

cwbotbot commented Mar 9, 2026

Test Results

e2e-aws

e2e-aks

@joshbranham
Copy link
Copy Markdown
Contributor Author

/test e2e-aks

@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci bot commented Mar 10, 2026

@joshbranham: 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.

@enxebre
Copy link
Copy Markdown
Member

enxebre commented Mar 10, 2026

/approve
/verified by unit test @joshbranham

@openshift-ci-robot
Copy link
Copy Markdown

@enxebre: This PR has been marked as verified by unit test @joshbranham.

Details

In response to this:

/approve
/verified by unit test @joshbranham

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.

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Mar 10, 2026
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci bot commented Mar 10, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enxebre, joshbranham, maxcao13

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 10, 2026
@openshift-merge-bot openshift-merge-bot bot merged commit 08198a1 into openshift:main Mar 10, 2026
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. area/api Indicates the PR includes changes for the API area/karpenter-operator Indicates the PR includes changes related to the Karpenter operator jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants