Skip to content

Conversation

@theobarberbany
Copy link
Contributor

@theobarberbany theobarberbany commented Nov 14, 2025

Ignore the coderabbit summary, it's wrong.

Ths adds a VAP on MAPI Machines that does not allow transitioning the spec.AuthoritativeAPI if doing so would produce an unpredictable result: if the CAPI mirror is deleting, or if infrastructureReady is not true.

Summary by CodeRabbit

  • New Features
    • Added an admission control policy for the Machine API that blocks changes to a machine's authoritative API field unless the related infrastructure is ready and also prevents such changes while a machine is being deleted.
  • Tests
    • Added comprehensive tests covering infrastructure readiness, deletion state, missing or mismatched resources/parameters, mixed edge cases, and expected warning/error messages to validate enforcement behavior.

✏️ Tip: You can customize this high-level summary in your review settings.

@openshift-ci-robot
Copy link

Pipeline controller notification
This repository 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. Review these jobs and use /test <job> to manually trigger optional jobs most likely to be impacted by the proposed changes.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Nov 14, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 14, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 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.21.0" version, but no target version was set.

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

@theobarberbany theobarberbany marked this pull request as draft November 14, 2025 17:45
@coderabbitai
Copy link

coderabbitai bot commented Nov 14, 2025

Walkthrough

Adds a new ValidatingAdmissionPolicy and matching Binding (scoped to openshift-machine-api) that blocks Machine spec.authoritativeAPI changes unless the related CAPI infrastructure is ready and the CAPI Machine is not deleting, and expands controller tests exercising many transition scenarios.

Changes

Cohort / File(s) Summary
Admission policy & binding
manifests/0000_30_cluster-api_09_admission-policies.yaml
Added ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding named openshift-mapi-authoritative-api-transition-requires-capi-infrastructure-ready-and-not-deleting. Binding targets openshift-machine-api and sets parameterNotFoundAction: Allow. Policy matches UPDATE on machine.openshift.io machines, defines variables (authAPIChanged, capiInfraReady, capiDeleting) and CEL validations to block spec.authoritativeAPI transitions when infra is not ready or CAPI is deleting.
Controller tests
pkg/controllers/machinesync/machine_sync_controller_test.go
Added a large test context covering MAPI authoritativeAPI transition scenarios: infra readiness (true/false/missing), CAPI deletion timestamp states, presence/absence of CAPI Machine, parameter matching, sentinel machine verification, non-authoritative updates, mixed edge cases, and expected allow/deny outcomes and messages.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant Client
    participant MAPI as "OpenShift Machine API"
    participant Admission as "Admission Controller"
    participant VAP as "ValidatingAdmissionPolicy\nopenshift-mapi-authoritative-api-transition-...-and-not-deleting"
    participant CAPI as "CAPI infra state"

    Client->>MAPI: UPDATE Machine (spec.authoritativeAPI change)
    MAPI->>Admission: submit admission request
    Admission->>VAP: evaluate matchConstraints & matchConditions
    VAP->>CAPI: read infra readiness & deletion status (variables)
    alt infraReady AND not deleting
        VAP-->>Admission: validation passes
        Admission-->>MAPI: allow request
        MAPI-->>Client: 200 OK
    else infra not ready OR CAPI deleting
        VAP-->>Admission: validation denies (CEL fails)
        Admission-->>MAPI: deny request with message
        MAPI-->>Client: 4xx Denied
    end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

  • Pay special attention to:
    • CEL expressions, variable extraction, and logic in the added ValidatingAdmissionPolicy.
    • matchConstraints and parameterNotFoundAction semantics in the Binding.
    • Test setup complexity, sentinel machines, and asserted deny message text in pkg/controllers/machinesync/machine_sync_controller_test.go.

Poem

🐇 I hopped through YAML, crisp and steady,
Watching switches, ready and heady.
If infra’s true and CAPI stays kind,
The authoritative flip is allowed to find.
🥕🌙

Pre-merge checks and finishing touches

✅ 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 directly and accurately describes the main change: adding admission policy rules that prevent authoritativeAPI transitions when CAPI Machine is deleting or infrastructure is not ready.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 5806dd9 and 0879a53.

📒 Files selected for processing (2)
  • manifests/0000_30_cluster-api_09_admission-policies.yaml (2 hunks)
  • pkg/controllers/machinesync/machine_sync_controller_test.go (1 hunks)
🔇 Additional comments (5)
manifests/0000_30_cluster-api_09_admission-policies.yaml (1)

482-554: VAP semantics match the intended safety guard on authoritativeAPI transitions

The binding/paramKind/matchConstraints wiring and CEL logic on variables.authAPIChanged, variables.capiInfraReady and variables.capiDeleting correctly enforce:

  • Deny when spec.authoritativeAPI changes and the CAPI Machine infra is not true (including missing status/field due to orValue(false)).
  • Deny when spec.authoritativeAPI changes and the CAPI Machine is deleting.
  • Allow when no CAPI param exists via parameterNotFoundAction: Allow.

This aligns with the PR description and existing patterns in this file (including the non‑SA matchCondition and namespace scoping). I don’t see further changes needed here.

pkg/controllers/machinesync/machine_sync_controller_test.go (4)

1879-1928: New VAP test harness is consistent with existing admission-policy patterns

The setup for the new vapName context (waiting for the policy, adding sentinel validation, rebinding namespaces, and using a sentinel MAPI/CAPI pair with VerifySentinelValidation) mirrors the existing VAP test scaffolding and ensures we’re actually exercising this specific policy. This looks correct and maintains good isolation between test suites.


1930-1995: Infrastructure readiness tests align with CEL behavior and messages

The infra‑readiness tests correctly:

  • Cover InfrastructureReady=false, missing field, and missing status as all mapping to variables.capiInfraReady == false.
  • Require status.authoritativeAPI to be MachineAPI before attempting the transition.
  • Expect denial with a substring of the VAP message ("status.infrastructureReady is true"), which matches the manifest text.

This matches the CEL expression !(variables.authAPIChanged && !variables.capiInfraReady) and should be stable so long as the message string in the manifest doesn’t change materially.


1998-2078: Deletion and mixed‑state tests correctly gate transitions on CAPI deletionTimestamp

The deletion‑focused and mixed‑state cases correctly:

  • Require InfrastructureReady=true for the “deleting” paths where relevant.
  • Drive DeletionTimestamp by adding a finalizer and calling Delete, then assert it is non‑nil before attempting the update.
  • Verify that transitions are denied with an error containing "CAPI Machine is being deleted", matching the manifest’s validation message.
  • Cover both infraReady=true && deleting and infraReady=false && !deleting, ensuring each guard independently blocks the transition when its precondition is met.

The behavior matches !(variables.authAPIChanged && variables.capiDeleting) and the infra guard, and the flows look robust.


2098-2181: Trigger‑condition and param‑not‑found coverage looks solid

The “trigger conditions” and “CAPI Machine parameter is not found” contexts validate important edge cases:

  • Updating labels/annotations/spec (other than spec.authoritativeAPI) when infra is not ready or CAPI is deleting is allowed, confirming the policy only fires when authAPIChanged is true.
  • When there is no CAPI Machine with a matching name, the change is allowed, verifying that parameterNotFoundAction: Allow is effectively exercised.

This gives good confidence that the policy won’t over‑block unrelated updates and behaves as intended when the param is absent.

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

Error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions
The command is terminated due to an error: can't load config: unsupported version of the configuration: "" See https://golangci-lint.run/docs/product/migration-guide for migration instructions

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

  • Provide your own instructions using the high_level_summary_instructions setting.
  • Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
  • Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

  1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
  2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
  3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
  4. 📊 Contributor Summary — Include a Markdown table showing contributions:
    | Contributor | Lines Added | Lines Removed | Files Changed |
  5. ✔️ Additional Notes — Add any extra reviewer context.
    Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.


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

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 14, 2025
@openshift-ci openshift-ci bot requested review from RadekManak and nrb November 14, 2025 17:45
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 14, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 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.21.0" version, but no target version was set.

In response to this:

Summary by CodeRabbit

  • New Features
  • Introduced a new admission control policy for machine API that validates configuration transitions. The policy enforces infrastructure readiness requirements before allowing changes and prevents modifications during machine deletion, providing additional safeguards for cluster operational consistency and stability.

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

@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

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between 47a337a and f839fc4.

📒 Files selected for processing (1)
  • manifests/0000_30_cluster-api_09_admission-policies.yaml (2 hunks)
🔇 Additional comments (2)
manifests/0000_30_cluster-api_09_admission-policies.yaml (2)

435-454: Policy binding structure looks correct.

The ValidatingAdmissionPolicyBinding correctly targets the openshift-machine-api namespace with appropriate parameterNotFoundAction: Allow and references the corresponding policy. Structure and namespace scoping align with existing patterns in the file.


456-483: Policy definition structure is sound, pending variable reference fix.

The ValidatingAdmissionPolicy correctly:

  • Targets MAPI machines (machine.openshift.io v1beta1) on UPDATE operations
  • Uses CAPI machines as params (cluster.x-k8s.io/v1beta1)
  • Excludes service accounts via matchCondition
  • Validates name matching between MAPI and CAPI machines
  • Defines appropriate variables for infrastructure readiness and deletion status

Once the variable references in the validations are corrected (see previous comment), the policy structure will properly enforce the intended constraints.

@theobarberbany theobarberbany force-pushed the tb/prevent-authapi-change-if-unsuitable branch 4 times, most recently from 2007632 to 7211ded Compare November 19, 2025 12:18
@theobarberbany theobarberbany force-pushed the tb/prevent-authapi-change-if-unsuitable branch 2 times, most recently from 38d7255 to b2e0a76 Compare November 19, 2025 14:42
@theobarberbany theobarberbany marked this pull request as ready for review November 19, 2025 14:48
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 19, 2025
@openshift-ci openshift-ci bot requested review from chrischdi and damdo November 19, 2025 14:49
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 19, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 which is a valid jira issue.

In response to this:

Summary by CodeRabbit

  • New Features
  • Added an admission control policy for the Machine API that blocks authoritative API transitions unless underlying infrastructure is ready and prevents changes while a machine is being deleted.
  • Tests
  • Added comprehensive tests validating policy behavior across readiness, deletion, and edge-case scenarios to ensure consistent enforcement and messaging.

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

@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: 0

🧹 Nitpick comments (1)
pkg/controllers/machinesync/machine_sync_controller_test.go (1)

1879-2207: Comprehensive coverage of new VAP behavior; consider minor helper extraction

The new "when validating MAPI authoritativeAPI transitions" context exercises the new VAP very well:

  • Confirms denials for all “unsafe” CAPI states (infra not ready, missing status, deleting, mixed ready+deleting / not‑ready+non‑deleting).
  • Confirms success paths (infraReady=true & not deleting, no CAPI counterpart, and non‑authoritative updates).
  • Wires the binding namespaces and sentinel validation exactly like the existing VAP suites, so we know the policy is actually in play rather than relying on static YAML.

From a test‑design perspective this looks solid. If you want to trim duplication later, the repeated setup patterns (setCAPIInfraReady(true/false), markCapiDeleting, setMapiAuthoritativeAPIStatusMachineAPIAndSpecClusterAPI) could be factored into small helpers, but that’s optional and in line with the rest of the file’s style.

If you’d like, I can sketch small helper functions for the repeated “set infra / set deleting / flip authoritativeAPI” sequences to keep future scenarios easier to add.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between f839fc4 and b2e0a76.

📒 Files selected for processing (2)
  • manifests/0000_30_cluster-api_09_admission-policies.yaml (2 hunks)
  • pkg/controllers/machinesync/machine_sync_controller_test.go (1 hunks)
🔇 Additional comments (1)
manifests/0000_30_cluster-api_09_admission-policies.yaml (1)

482-555: New VAP correctly enforces infra‑ready & non‑deleting CAPI preconditions for MAPI authoritativeAPI changes

The mapi-authapi-transition-requires-capi-ready binding/policy is wired consistently with the existing VAPs: it scopes validation to openshift-machine-api MAPI Machines, uses CAPI Machines as params, matches only name‑paired resources, and cleanly encodes the two required guards:

  • authAPIChanged && !capiInfraReady is rejected, treating missing/absent status.infrastructureReady as not ready via optional access + .orValue(false).
  • authAPIChanged && capiDeleting is rejected using has(params.metadata.deletionTimestamp).

The use of parameterNotFoundAction: Allow plus the name match ensures Machines without a CAPI counterpart are not blocked, matching the tests. Variable references all use the variables. prefix, so CEL evaluation should work as intended.

If you want extra assurance, it’s worth running this VAP against a live envtest or dev cluster to confirm the interplay with the existing openshift-prevent-migration-when-machine-updating policy doesn’t introduce any unexpected double‑validation behavior around .spec.authoritativeAPI updates.

@theobarberbany theobarberbany force-pushed the tb/prevent-authapi-change-if-unsuitable branch from b2e0a76 to 5806dd9 Compare November 19, 2025 18:36
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 19, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 which is a valid jira issue.

In response to this:

Summary by CodeRabbit

  • New Features
  • Added an admission control policy for the Machine API that blocks changes to a machine's authoritative API field unless related infrastructure is ready and also prevents such changes while a machine is being deleted.
  • Tests
  • Added comprehensive tests covering readiness, deletion, missing-resource, parameter-mismatch, and edge-case scenarios to validate enforcement logic and warning/error messaging.

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

@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: 0

🧹 Nitpick comments (1)
pkg/controllers/machinesync/machine_sync_controller_test.go (1)

1931-2207: Consider reducing repetition in authoritativeAPI transition test setup

Many tests repeat the same pattern of “set Status.AuthoritativeAPI to MachineAPI and then update Spec.AuthoritativeAPI (and often CAPI infra/deletion state)”. If this block continues to grow, you might factor those sequences into small helpers or a table‑driven sub‑suite to keep individual It bodies shorter and the intent a bit clearer. Behavior is fine as is; this is just a maintainability tweak.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to data retention organization setting

📥 Commits

Reviewing files that changed from the base of the PR and between b2e0a76 and 5806dd9.

📒 Files selected for processing (2)
  • manifests/0000_30_cluster-api_09_admission-policies.yaml (2 hunks)
  • pkg/controllers/machinesync/machine_sync_controller_test.go (1 hunks)
🔇 Additional comments (2)
pkg/controllers/machinesync/machine_sync_controller_test.go (1)

1879-2207: VAP transition tests accurately capture infra/deletion semantics

This context does a good job exercising all the important paths for the new policy: infraReady=false/missing/true, deletionTimestamp set/clear, mixed states, non‑auth changes, and the param‑not‑found case. The expectations on error substrings line up with the policy messages, and the use of Eventually/k.Update(Status) is consistent with the rest of the suite. I don’t see correctness issues here.

manifests/0000_30_cluster-api_09_admission-policies.yaml (1)

482-555: New mapi-authapi-transition-requires-capi-ready policy matches intended behavior

The binding and policy wiring look correct: scope is openshift-machine-api, params are CAPI Machines in openshift-cluster-api (with parameterNotFoundAction: Allow), and match conditions mirror existing patterns. The CEL variables (authAPIChanged, capiInfraReady, capiDeleting) are correctly referenced via variables.*, and the validations enforce exactly the intended rule: any spec.authoritativeAPI change is denied unless infra is ready and the CAPI Machine is not deleting, while non‑auth spec/metadata changes remain unaffected. This aligns with the added tests.

@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 19, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 which is a valid jira issue.

In response to this:

Ignore the coderabbit summary, it's wrong.

Ths adds a VAP on MAPI Machines that does not allow transitioning the spec.AuthoritativeAPI if doing so would produce an unpredictable result: if the CAPI mirror is deleting, or if infrastructureReady is not true.

Summary by CodeRabbit

  • New Features
  • Added an admission control policy for the Machine API that blocks changes to a machine's authoritative API field unless related infrastructure is ready and also prevents such changes while a machine is being deleted.
  • Tests
  • Added comprehensive tests covering readiness, deletion, missing-resource, parameter-mismatch, and edge-case scenarios to validate enforcement logic and warning/error messaging.

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.

@theobarberbany
Copy link
Contributor Author

/test e2e-aws-capi-techpreview
/test regression-clusterinfra-aws-ipi-techpreview-capi

@nrb
Copy link
Contributor

nrb commented Nov 19, 2025

/lgtm
/approve

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 19, 2025
@openshift-ci-robot
Copy link

Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 19, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nrb

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 /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 Nov 19, 2025
@damdo
Copy link
Member

damdo commented Nov 20, 2025

/hold

To coordinate merge with: #410

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 20, 2025
Copy link
Member

@damdo damdo left a comment

Choose a reason for hiding this comment

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

Thanks

A couple of naming nits but LGTM

@theobarberbany
Copy link
Contributor Author

A couple of naming nits but LGTM

sigh this is what I get for using AI to help with naming lol

Will update.

@theobarberbany theobarberbany force-pushed the tb/prevent-authapi-change-if-unsuitable branch from 5806dd9 to 0879a53 Compare November 20, 2025 15:35
@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Nov 20, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Nov 20, 2025

@theobarberbany: This pull request references OCPCLOUD-2997 which is a valid jira issue.

In response to this:

Ignore the coderabbit summary, it's wrong.

Ths adds a VAP on MAPI Machines that does not allow transitioning the spec.AuthoritativeAPI if doing so would produce an unpredictable result: if the CAPI mirror is deleting, or if infrastructureReady is not true.

Summary by CodeRabbit

  • New Features
  • Added an admission control policy for the Machine API that blocks changes to a machine's authoritative API field unless the related infrastructure is ready and also prevents such changes while a machine is being deleted.
  • Tests
  • Added comprehensive tests covering infrastructure readiness, deletion state, missing or mismatched resources/parameters, mixed edge cases, and expected warning/error messages to validate enforcement behavior.

✏️ Tip: You can customize this high-level summary in your review settings.

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
Member

@damdo damdo left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Nov 20, 2025
@openshift-ci-robot
Copy link

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-capi-techpreview
/test e2e-aws-ovn
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-aws-ovn-techpreview
/test e2e-aws-ovn-techpreview-upgrade
/test e2e-azure-capi-techpreview
/test e2e-azure-ovn-techpreview
/test e2e-azure-ovn-techpreview-upgrade
/test e2e-gcp-capi-techpreview
/test e2e-gcp-ovn-techpreview
/test e2e-metal3-capi-techpreview
/test e2e-openstack-capi-techpreview
/test e2e-openstack-ovn-techpreview
/test e2e-vsphere-capi-techpreview
/test regression-clusterinfra-aws-ipi-techpreview-capi

@sunzhaohua2
Copy link
Contributor

/assign @miyadav

for testing

@miyadav
Copy link
Member

miyadav commented Nov 25, 2025

/retest-required

@miyadav
Copy link
Member

miyadav commented Nov 25, 2025

functionally looks good , verified by test , will add label once tests passes in ci.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Nov 25, 2025

@theobarberbany: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/regression-clusterinfra-aws-ipi-techpreview-capi 0879a53 link false /test regression-clusterinfra-aws-ipi-techpreview-capi
ci/prow/e2e-metal3-capi-techpreview 0879a53 link false /test e2e-metal3-capi-techpreview
ci/prow/e2e-aws-ovn 0879a53 link true /test e2e-aws-ovn
ci/prow/e2e-openstack-capi-techpreview 0879a53 link true /test e2e-openstack-capi-techpreview
ci/prow/e2e-openstack-ovn-techpreview 0879a53 link true /test e2e-openstack-ovn-techpreview

Full PR test history. Your PR dashboard.

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.

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. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants