✨ Propagate ClusterExtensionRevision conditions to ClusterExtension status

[perdasilva]

Description

• ClusterExtension's Available and Progressing conditions are equal to the counterparts on the latest installed active revision
• When a new revision is rolling out, mirror its Progressing condition to its counterpart on ClusterExtension to improve visibility and to signal that a transition is in progress
• Adds .status.activeRevisions field to the ClusterExtension to track the active revisions and mirrors Available and Progressing conditions for those not marked yet as installed

This changes opens up a possibility for an observer to get insights on ClusterExtension update process:

• When Reason on Progressing condition flips to RollingOut, an update is in progress
• More then one revision could be listed under .status.activeRevisions during upgrade (installed + those in progress)
• Available and Progressing conditions of an active, but not yet available revision, are listed under .status.activeRevisions.conditions so that can be easier to understand update issues

The new behavior is marked as experimental behind Boxcutter feature gate.

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	3816d20
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/6939679e3497bd0008b2cf3f
😎 Deploy Preview	https://deploy-preview-2281--olmv1.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[perdasilva]

/hold wip

[codecov]

Codecov Report

❌ Patch coverage is 89.83051% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.81%. Comparing base (ff7d3c2) to head (3816d20).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
api/v1/zz_generated.deepcopy.go	66.66%	6 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #2281 +/- ##
==========================================
- Coverage 74.88% 74.81% -0.08% 
==========================================
Files 95 95 Lines 7323 7377 +54 ==========================================
+ Hits 5484 5519 +35 - Misses 1407 1421 +14 - Partials 432 437 +5 

Flag	Coverage Δ
e2e	44.65% <0.00%> (-0.29%)	⬇️
experimental-e2e	49.23% <89.83%> (-0.12%)	⬇️
unit	58.39% <0.00%> (-0.44%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull Request Overview

This PR refactors the ClusterExtension reconciliation process to use a step-based architecture and updates condition handling to use Available and Progressing conditions instead of the legacy Installed condition. The changes support better status reporting from ClusterExtensionRevision objects and introduce an ActiveRevisions status field.

Key changes:

• Introduces a step-based reconciliation pattern using ReconcileStepFunc to break down the reconcile logic into composable steps
• Updates CRD printer columns and status types to use Available instead of Installed condition
• Adds Progressing condition to ClusterExtensionRevision with new reasons like RollingOut, RolloutError, and RolledOut
• Introduces ActiveRevisions status field to track active revisions in ClusterExtension status
• Adds new test data for v1.0.2 test-operator bundle with httpd-based container setup

Reviewed Changes

Copilot reviewed 30 out of 30 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
internal/operator-controller/controllers/clusterextension_reconcile_steps.go	New file implementing generic reconcile steps for finalizers, revision states, metadata retrieval, bundle unpacking, and application
internal/operator-controller/controllers/boxcutter_reconcile_steps.go	New file with boxcutter-specific reconcile steps including storage migration and condition mirroring
internal/operator-controller/controllers/clusterextension_controller.go	Refactored to remove inline reconcile logic, moved to step-based architecture with ReconcileSteps
internal/operator-controller/controllers/clusterextensionrevision_controller.go	Updated condition handling to use new helper methods and improved status messages with version information
api/v1/clusterextensionrevision_types.go	Added helper methods for marking revision status and new condition constants
api/v1/clusterextension_types.go	Added RevisionStatus type and ActiveRevisions field to status
CRD manifests	Updated printer columns from Installed to Available and added ActiveRevisions schema
Test files	Updated to use new reconciler setup pattern with options, updated expected conditions
Test data	Added v1.0.2 bundle with httpd container setup and updated v1.0.0/v1.2.0 bundles

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[pedjak]

/unhold ready for review

[Copilot]

Pull request overview

Copilot reviewed 20 out of 20 changed files in this pull request and generated 9 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[perdasilva]

From yesterday's discussion, should we stick to annotations?

[perdasilva]

Not for this PR, but I wonder if we should carry the CE generation as an annotation on the CER...

[perdasilva]

How come we need this?

[perdasilva]

Because there's no upgrade edge between 1.0.1 and 1.0.2? should we call it out in a comment?

[michaelryanpeter]

LGTM

[perdasilva]

/approve

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The condition retrieved from i.Conditions is being modified directly (line 122) before being passed to SetStatusCondition. According to the repository convention, conditions from ClusterExtensionRevision should be deep-copied before modification when propagating to ClusterExtension status.

Suggested fix:

ifcnd:=apimeta.FindStatusCondition(i.Conditions, cndType); cnd!=nil {
cndCopy:=cnd.DeepCopy()
cndCopy.ObservedGeneration=ext.GetGeneration()
apimeta.SetStatusCondition(&ext.Status.Conditions, *cndCopy)
}

Suggested change

	cnd.ObservedGeneration=ext.GetGeneration()
	apimeta.SetStatusCondition(&ext.Status.Conditions, *cnd)
	cndCopy:=cnd.DeepCopy()
	cndCopy.ObservedGeneration=ext.GetGeneration()
	apimeta.SetStatusCondition(&ext.Status.Conditions, *cndCopy)

[Copilot]

This code attempts to find a condition in rs.Conditions, but rs was just created on line 132 with only the Name field set and an empty Conditions slice. This means apimeta.FindStatusCondition(rs.Conditions, cndType) will always return nil, making lines 134-137 ineffective.

The intended logic appears to be finding the condition from r.Conditions (the source RevisionMetadata), not rs.Conditions (the destination RevisionStatus).

Suggested fix:

ifcnd:=apimeta.FindStatusCondition(r.Conditions, cndType); cnd!=nil {
cndCopy:=cnd.DeepCopy()
cndCopy.ObservedGeneration=ext.GetGeneration()
apimeta.SetStatusCondition(&rs.Conditions, *cndCopy)
}

Suggested change

	ifcnd:=apimeta.FindStatusCondition(rs.Conditions, cndType); cnd!=nil {
	cnd.ObservedGeneration=ext.GetGeneration()
	apimeta.SetStatusCondition(&rs.Conditions, *cnd)
	ifcnd:=apimeta.FindStatusCondition(r.Conditions, cndType); cnd!=nil {
	cndCopy:=cnd.DeepCopy()
	cndCopy.ObservedGeneration=ext.GetGeneration()
	apimeta.SetStatusCondition(&rs.Conditions, *cndCopy)

[Copilot]

The field description in the generated documentation is incomplete compared to the API type definition. The API type has a more detailed description explaining:

• "conditions optionally expose Progressing and Available condition of the revision"
• "in case when it is not yet marked as successfully installed (condition Succeeded is not set to True)"
• "Given that a ClusterExtension should remain available during upgrades, an observer may use these conditions to get more insights about reasons for its current state"

However, the generated documentation only shows "Conditions is a set of conditions associated with the revision."

This suggests the documentation generation tool may not be picking up the full comment from the API type (lines 479-482 in api/v1/clusterextension_types.go). Please verify that the documentation generation correctly extracts the full field description.

Suggested change

|`conditions`_[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#condition-v1-meta) array_| Conditions is a set of conditions associated with the revision. |||

|`conditions`_[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.31/#condition-v1-meta) array_| Conditions optionally expose Progressing and Available condition of the revision. In case when it is not yet marked as successfully installed (condition Succeeded is not set to True), these conditions provide additional insight. Given that a ClusterExtension should remain available during upgrades, an observer may use these conditions to get more insights about reasons for its current state. |||

[dtfranz]

/lgtm

[rashmigottipati]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: perdasilva, rashmigottipati

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:

• OWNERS [perdasilva]

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