Skip to content

Conversation

@chrischdi
Copy link
Contributor

@chrischdi chrischdi commented Oct 13, 2025

Part of OCPCLOUD-3104 and required to merge:

Summary by CodeRabbit

  • Bug Fixes

    • Improved accuracy and consistency of MachineSet status reporting across API versions by merging condition sets before applying status updates, reducing flicker and mismatches during syncs and upgrades.
  • Refactor

    • Unified status synchronization to merge and apply condition sets atomically for more predictable status visibility across control-plane paths.
  • Chores

    • Removed automated removal of cluster-level webhook and CRD conversion entries during manifest customization.

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

openshift-ci-robot commented Oct 13, 2025

@chrischdi: This pull request references OCPCLOUD-3104 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 task to target the "4.21.0" version, but no target version was set.

In response to this:

Part of OCPCLOUD-3104 and required to merge:

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 openshift-ci bot requested review from mdbooth and nrb October 13, 2025 12:15
@coderabbitai
Copy link

coderabbitai bot commented Oct 13, 2025

Walkthrough

Merge-based refactor of MachineSet status updates: Conditions from converted CAPI/MAPI MachineSets are merged into existing objects, merged Conditions are copied back to converted objects, then the existing Status is overwritten with the converted Status; ObservedGeneration/SynchronizedGeneration/AuthoritativeAPI are handled separately. Also removed webhook-removal helpers from manifests generation.

Changes

Cohort / File(s) Summary
MachineSet status merging
pkg/controllers/machinesetsync/machineset_sync_controller.go
Replaced per-field status assignments with a condition-merge flow: merge converted v1beta1/v1beta2 Conditions into existing.Status, copy merged Conditions back to converted.Status, then overwrite existing.Status = converted.Status. Notes that ObservedGeneration, SynchronizedGeneration and AuthoritativeAPI are handled after/elsewhere.
Manifests generation — removed webhook filters
manifests-gen/customizations.go, manifests-gen/providercustomizations.go
Deleted calls and helper functions that removed cluster-level mutating/validating webhook entries and CRD conversion webhook filtering; removed associated imports and the removeConversionWebhook implementation. Remaining customization logic unchanged.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor Reconciler
  participant Existing as Existing MachineSet (CAPI/MAPI)
  participant Converted as Converted MachineSet (v1beta1/v1beta2)
  participant API as Kubernetes API

  Reconciler->>Converted: Build converted.Status (includes Conditions)
  Reconciler->>Existing: Read existing.Status
  Note over Reconciler,Existing: For each Condition in Converted, merge into Existing.Status.Conditions
  Reconciler->>Converted: Copy merged Conditions back to Converted.Status
  Reconciler->>Existing: Overwrite Existing.Status = Converted.Status
  Reconciler->>API: PATCH/UPDATE existing Status subresource
  API-->>Reconciler: Status update response
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

I hop through diffs with whiskered care,
I merge the conditions, fluff the air.
Webhooks folded, statuses aligned,
Tiny paws tidy every bind.
Hooray — a synced, well-ordered pair. 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title “OCPCLOUD-3104: Fix v1beta2 condition setting” clearly references the related JIRA issue and succinctly describes the core change in the pull request, which is updating how v1beta2 conditions are merged and applied in the MachineSet status synchronization logic.
✨ 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 ae094eb and 3a2f255.

📒 Files selected for processing (2)
  • manifests-gen/customizations.go (0 hunks)
  • manifests-gen/providercustomizations.go (0 hunks)
💤 Files with no reviewable changes (2)
  • manifests-gen/customizations.go
  • manifests-gen/providercustomizations.go

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 13, 2025

@chrischdi: This pull request references OCPCLOUD-3104 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 task to target the "4.21.0" version, but no target version was set.

In response to this:

Part of OCPCLOUD-3104 and required to merge:

Summary by CodeRabbit

  • Bug Fixes

  • Improved accuracy and consistency of MachineSet status reporting across API versions, reducing mismatches and flickering during sync and upgrades.

  • Refactor

  • Streamlined status synchronization with atomic updates that prioritize conditions, aligning behavior across control-plane paths for more predictable and reliable status visibility.

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/machinesetsync/machineset_sync_controller.go (1)

1000-1024: Consider adding inline comments to clarify the condition merging pattern.

The logic of merging conditions into existingCAPIMachineSet, copying them back to convertedCAPIMachineSet, and then overwriting the entire status is correct but non-obvious. This pattern ensures LastTransitionTime is properly managed while updating all status fields atomically.

Add inline comments explaining why conditions are copied back before the final overwrite:

 func setChangedCAPIMachineSetStatusFields(existingCAPIMachineSet, convertedCAPIMachineSet *clusterv1.MachineSet) {
-	// convertedCAPIMachine holds the computed and desired status changes converted from the source MAPI machine, so apply them to the existing existingCAPIMachine.
-	// Merge the v1beta1 conditions.
+	// Strategy: Merge conditions into existing (to preserve LastTransitionTime), 
+	// copy them back to converted, then overwrite entire status with converted.
+	
+	// Merge v1beta1 conditions: conditions.Set() updates LastTransitionTime only when status changes.
 	for _, condition := range convertedCAPIMachineSet.Status.Conditions {
 		conditions.Set(existingCAPIMachineSet, &condition)
 	}
 
-	// Copy them back to the convertedCAPIMachine.
+	// Copy merged conditions back so the final overwrite includes them.
 	convertedCAPIMachineSet.Status.Conditions = existingCAPIMachineSet.Status.Conditions
 
-	// Merge the v1beta2 conditions.
+	// Repeat for v1beta2 conditions if present.
 	if convertedCAPIMachineSet.Status.V1Beta2 != nil {
 		if existingCAPIMachineSet.Status.V1Beta2 == nil {
 			existingCAPIMachineSet.Status.V1Beta2 = &clusterv1.MachineSetV1Beta2Status{}
 		}
 
 		for _, condition := range convertedCAPIMachineSet.Status.V1Beta2.Conditions {
 			conditionsv1beta2.Set(existingCAPIMachineSet, condition)
 		}
 
-		// Copy them back to the convertedCAPIMachine.
+		// Copy merged v1beta2 conditions back.
 		convertedCAPIMachineSet.Status.V1Beta2.Conditions = existingCAPIMachineSet.Status.V1Beta2.Conditions
 	}
 
-	// Finally overwrite the entire existingCAPIMachine status with the convertedCAPIMachine status.
+	// Overwrite entire status: merged conditions plus all other fields from conversion.
 	existingCAPIMachineSet.Status = convertedCAPIMachineSet.Status
 }
📜 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 eea205c and 682e9ff.

📒 Files selected for processing (1)
  • pkg/controllers/machinesetsync/machineset_sync_controller.go (1 hunks)
🔇 Additional comments (2)
pkg/controllers/machinesetsync/machineset_sync_controller.go (2)

1062-1074: MAPI status handling inconsistent with AI-generated summary.

The AI summary states that "MAPI MachineSet status update logic was adjusted to align with the CAPIM changes" and "overwrites the entire status similarly to CAPIMachineSet." However, setChangedMAPIMachineSetStatusFields remains unchanged (no ~ marks) and still uses direct field assignments (lines 1064-1069) rather than the "merge conditions, copy back, overwrite entire status" pattern used in the CAPI version.

This inconsistency raises questions:

  1. Was the MAPI function intentionally left unchanged?
  2. Does MAPI not have v1beta2 conditions, making the simpler approach sufficient?
  3. Should MAPI adopt the same pattern as CAPI for consistency?

Clarify whether the different handling is intentional or if further alignment is needed.


1000-1024: Ensure v1beta2 status isn’t dropped when nil
If convertedCAPIMachineSet.Status.V1Beta2 can ever be nil, the final assignment at line 1024 will clear any existing V1Beta2 status. Confirm that conversion always initializes Status.V1Beta2, or add logic to preserve the existing V1Beta2 status when the converted one is nil.

@chrischdi
Copy link
Contributor Author

/assign @damdo

@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 13, 2025

@chrischdi: This pull request references OCPCLOUD-3104 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 task to target the "4.21.0" version, but no target version was set.

In response to this:

Part of OCPCLOUD-3104 and required to merge:

Summary by CodeRabbit

  • Bug Fixes

  • Improved accuracy and consistency of MachineSet status reporting across API versions, reducing mismatches and flickering during sync and upgrades by ensuring condition merges are preserved.

  • Refactor

  • Streamlined status synchronization to merge and apply condition sets atomically, aligning behavior across control-plane paths for more predictable and reliable status visibility and updates.

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

🧹 Nitpick comments (1)
pkg/controllers/machinesetsync/machineset_sync_controller.go (1)

1066-1072: Consider removing redundant field assignments.

Lines 1066-1072 set fields on existingMAPIMachineSet that are immediately overwritten by line 1086's full status assignment. Since convertedMAPIMachineSet already contains these fields, the direct assignments are redundant.

Consider removing these lines for clarity:

 func setChangedMAPIMachineSetStatusFields(existingMAPIMachineSet, convertedMAPIMachineSet *mapiv1beta1.MachineSet) {
 	// convertedMAPIMachineSet holds the computed and desired status changes, so apply them to the existing existingMAPIMachineSet.
-	existingMAPIMachineSet.Status.Replicas = convertedMAPIMachineSet.Status.Replicas
-	existingMAPIMachineSet.Status.ReadyReplicas = convertedMAPIMachineSet.Status.ReadyReplicas
-	existingMAPIMachineSet.Status.AvailableReplicas = convertedMAPIMachineSet.Status.AvailableReplicas
-	existingMAPIMachineSet.Status.FullyLabeledReplicas = convertedMAPIMachineSet.Status.FullyLabeledReplicas
-	existingMAPIMachineSet.Status.ErrorReason = convertedMAPIMachineSet.Status.ErrorReason
-	existingMAPIMachineSet.Status.ErrorMessage = convertedMAPIMachineSet.Status.ErrorMessage
-
 	// Merge the v1beta1 conditions.
📜 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 682e9ff and ae094eb.

📒 Files selected for processing (1)
  • pkg/controllers/machinesetsync/machineset_sync_controller.go (3 hunks)

Comment on lines 1000 to 1026
func setChangedCAPIMachineSetStatusFields(existingCAPIMachineSet, convertedCAPIMachineSet *clusterv1.MachineSet) {
// convertedCAPIMachineSet holds the computed and desired status changes, so apply them to the existing existingCAPIMachineSet.
// Set the changed v1beta1 fields.
existingCAPIMachineSet.Status.Replicas = convertedCAPIMachineSet.Status.Replicas
existingCAPIMachineSet.Status.ReadyReplicas = convertedCAPIMachineSet.Status.ReadyReplicas
existingCAPIMachineSet.Status.AvailableReplicas = convertedCAPIMachineSet.Status.AvailableReplicas
existingCAPIMachineSet.Status.FullyLabeledReplicas = convertedCAPIMachineSet.Status.FullyLabeledReplicas
existingCAPIMachineSet.Status.FailureReason = convertedCAPIMachineSet.Status.FailureReason
existingCAPIMachineSet.Status.FailureMessage = convertedCAPIMachineSet.Status.FailureMessage

for i := range convertedCAPIMachineSet.Status.Conditions {
conditions.Set(existingCAPIMachineSet, &convertedCAPIMachineSet.Status.Conditions[i])
// convertedCAPIMachine holds the computed and desired status changes converted from the source MAPI machine, so apply them to the existing existingCAPIMachine.
// Merge the v1beta1 conditions.
for _, condition := range convertedCAPIMachineSet.Status.Conditions {
conditions.Set(existingCAPIMachineSet, &condition)
}

// Set the changed v1beta2 fields.
switch {
case convertedCAPIMachineSet.Status.V1Beta2 == nil:
existingCAPIMachineSet.Status.V1Beta2 = nil
case existingCAPIMachineSet.Status.V1Beta2 == nil:
existingCAPIMachineSet.Status.V1Beta2 = convertedCAPIMachineSet.Status.V1Beta2
default:
existingCAPIMachineSet.Status.V1Beta2.UpToDateReplicas = convertedCAPIMachineSet.Status.V1Beta2.UpToDateReplicas
existingCAPIMachineSet.Status.V1Beta2.AvailableReplicas = convertedCAPIMachineSet.Status.V1Beta2.AvailableReplicas
existingCAPIMachineSet.Status.V1Beta2.ReadyReplicas = convertedCAPIMachineSet.Status.V1Beta2.ReadyReplicas
// Copy them back to the convertedCAPIMachine.
convertedCAPIMachineSet.Status.Conditions = existingCAPIMachineSet.Status.Conditions

// Merge the v1beta2 conditions.
if convertedCAPIMachineSet.Status.V1Beta2 != nil {
if existingCAPIMachineSet.Status.V1Beta2 == nil {
existingCAPIMachineSet.Status.V1Beta2 = &clusterv1.MachineSetV1Beta2Status{}
}

for i := range convertedCAPIMachineSet.Status.V1Beta2.Conditions {
conditionsv1beta2.Set(existingCAPIMachineSet, convertedCAPIMachineSet.Status.V1Beta2.Conditions[i])
for _, condition := range convertedCAPIMachineSet.Status.V1Beta2.Conditions {
conditionsv1beta2.Set(existingCAPIMachineSet, condition)
}

// Copy them back to the convertedCAPIMachine.
convertedCAPIMachineSet.Status.V1Beta2.Conditions = existingCAPIMachineSet.Status.V1Beta2.Conditions
}

// Finally overwrite the entire existingCAPIMachine status with the convertedCAPIMachine status.
existingCAPIMachineSet.Status = convertedCAPIMachineSet.Status
}
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion | 🟠 Major

🧩 Analysis chain

Merge-copy-overwrite pattern correctly handles condition timestamps.

The refactored approach properly preserves LastTransitionTime for conditions:

  1. Merge conditions into existing (lines 1003-1005, 1016-1018)
  2. Copy merged conditions back to converted (lines 1008, 1021)
  3. Overwrite entire status (line 1025)

The addition of v1beta2 condition handling (lines 1011-1022) appears to be the fix mentioned in the PR title.

Please verify that v1beta2 condition merging has test coverage to ensure LastTransitionTime is correctly preserved during status updates and upgrades.


🏁 Script executed:

#!/bin/bash
# Search for tests covering v1beta2 condition handling in MachineSet sync
rg -n -C3 -g '**/*test.go' 'V1Beta2.*Condition|v1beta2.*condition' --type=go

Length of output: 38085


Add unit tests for v1beta2 condition merging in MachineSet sync controller

No existing tests under pkg/controllers/machinesetsync cover the new v1beta2 merge logic. Add unit tests for setChangedCAPIMachineSetStatusFields (and its counterpart) to verify that v1beta2 Conditions are merged correctly and LastTransitionTime is preserved.

🤖 Prompt for AI Agents
In pkg/controllers/machinesetsync/machineset_sync_controller.go around lines
1000 to 1026, add unit tests that exercise setChangedCAPIMachineSetStatusFields'
v1beta2 merging path: create test cases where
existingCAPIMachineSet.Status.V1Beta2 is nil and convertedCAPIMachineSet has one
or more v1beta2 Conditions, including Conditions with non-zero
LastTransitionTime, then call the function and assert that
existingCAPIMachineSet.Status.V1Beta2 is initialized, Conditions are
copied/merged from convertedCAPIMachineSet, and LastTransitionTime values are
preserved; also add complementary tests for the counterpart function that copies
back to converted objects to ensure symmetric behavior and edge cases (empty
conditions, overlapping condition types) are handled.

@damdo
Copy link
Member

damdo commented Oct 13, 2025

@chrischdi let me know when we are good with a review on this :) TY

@chrischdi
Copy link
Contributor Author

chrischdi commented Oct 13, 2025

@damdo Should be good for a review 👍

I think this even covers a bug, the selector was not copied over.

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.

/approve
/lgtm

/hold

For testing

@openshift-ci openshift-ci bot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lgtm Indicates that a PR is ready to be merged. labels Oct 13, 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

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 13, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: damdo

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 Oct 13, 2025
@chrischdi
Copy link
Contributor Author

/test e2e-azure-ovn-techpreview

looks like a flake

@chrischdi
Copy link
Contributor Author

e2e-openstack-ovn-techpreview seems to be permanently red.

@damdo
Copy link
Member

damdo commented Oct 14, 2025

e2e-openstack-ovn-techpreview seems to be permanently red.

It is perma-failing yes. We'll need to look into it. For now:

/override ci/prow/e2e-openstack-ovn-techpreview

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 14, 2025

@damdo: Overrode contexts on behalf of damdo: ci/prow/e2e-openstack-ovn-techpreview

In response to this:

e2e-openstack-ovn-techpreview seems to be permanently red.

It is perma-failing yes. We'll need to look into it. For now:

/override ci/prow/e2e-openstack-ovn-techpreview

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.

@chrischdi
Copy link
Contributor Author

/testwith openshift/cluster-api/master/e2e-aws-capi-techpreview openshift/cluster-api#243

@chrischdi
Copy link
Contributor Author

/testwith openshift/cluster-api/master/e2e-aws-capi-techpreview openshift/cluster-api#243 #385

@sunzhaohua2
Copy link
Contributor

/testwith openshift/cluster-capi-operator/main/e2e-aws-capi-techpreview openshift/cluster-api#243

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Oct 14, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Oct 14, 2025

@chrischdi: This pull request references OCPCLOUD-3104 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 task to target the "4.21.0" version, but no target version was set.

In response to this:

Part of OCPCLOUD-3104 and required to merge:

Summary by CodeRabbit

  • Bug Fixes

  • Improved accuracy and consistency of MachineSet status reporting across API versions by merging condition sets before applying status updates, reducing flicker and mismatches during syncs and upgrades.

  • Refactor

  • Unified status synchronization to merge and apply condition sets atomically for more predictable status visibility across control-plane paths.

  • Chores

  • Removed automated removal of cluster-level webhook and CRD conversion entries during manifest customization.

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.

@chrischdi chrischdi force-pushed the pr-fix-conditions-set-lasttransitiontime branch from 3a2f255 to ae094eb Compare October 14, 2025 14:51
@chrischdi
Copy link
Contributor Author

Let's see how far we get with conversion CAPI v1.11.2 and webhooks enabled. (Not a requirement for merging)

/testwith openshift/cluster-capi-operator/main/e2e-aws-capi-techpreview openshift/cluster-api/pull/248

@chrischdi
Copy link
Contributor Author

chrischdi commented Oct 14, 2025

/testwith abort

(abort because I did fail to push on openshift/cluster-api/pull/248

@chrischdi
Copy link
Contributor Author

Let's see how far we get with conversion CAPI v1.11.2 and webhooks enabled. (Not a requirement for merging)

/testwith openshift/cluster-capi-operator/main/e2e-aws-capi-techpreview openshift/cluster-api#248

@chrischdi
Copy link
Contributor Author

/testwith openshift/cluster-capi-operator/main/e2e-aws-capi-techpreview openshift/cluster-api#248

@damdo
Copy link
Member

damdo commented Oct 14, 2025

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 14, 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

@chrischdi
Copy link
Contributor Author

/retest

(we can ignore the multi-pr ci's)

@chrischdi
Copy link
Contributor Author

/retest

@damdo
Copy link
Member

damdo commented Oct 15, 2025

/override ci/prow/e2e-openstack-ovn-techpreview

as it is perma-failing

@damdo
Copy link
Member

damdo commented Oct 15, 2025

/skip

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 15, 2025

@damdo: Overrode contexts on behalf of damdo: ci/prow/e2e-openstack-ovn-techpreview

In response to this:

/override ci/prow/e2e-openstack-ovn-techpreview

as it is perma-failing

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.

@chrischdi
Copy link
Contributor Author

/verified bypass

Verified via https://prow.ci.openshift.org/view/gs/test-platform-results/logs/multi-pr-openshift-cluster-capi-operator-385-openshift-cluster-api-248-e2e-aws-capi-techpreview/1978118575797309440 which did not have the test failures related to lastTransitionTimestamp anymore regarding unset .status.v1beta2.conditions.lastTransitionTime

@chrischdi
Copy link
Contributor Author

/hold cancel

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Oct 15, 2025
@openshift-ci-robot
Copy link

@chrischdi: The verified label has been added.

In response to this:

/verified bypass

Verified via https://prow.ci.openshift.org/view/gs/test-platform-results/logs/multi-pr-openshift-cluster-capi-operator-385-openshift-cluster-api-248-e2e-aws-capi-techpreview/1978118575797309440 which did not have the test failures related to lastTransitionTimestamp anymore regarding unset .status.v1beta2.conditions.lastTransitionTime

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 openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Oct 15, 2025
@openshift-merge-bot openshift-merge-bot bot merged commit 372b2a5 into openshift:main Oct 15, 2025
26 of 29 checks passed
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Oct 15, 2025

@chrischdi: all tests passed!

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. 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.

4 participants