🌱 (fix) ClusterExtensionRevision had inconsistent owner labeling and confusing code

[camilamacedo86]

Problem

ClusterExtensionRevision had inconsistent owner labeling and confusing code:

1. Inconsistent Labels: Managed objects use owner-kind + owner-name, but ClusterExtensionRevision used only owner
2. Confusing Code: Variable named storeLbls actually contained annotations
3. Unclear API: Hard to understand what parameters were for

Solution

Fixed owner label consistency and improved code clarity while keeping bundle metadata in annotations (no breaking changes).

Changes

✅ Owner Label Unification

• All objects now use owner-kind + owner-name consistently

✅ Code Clarity

• Renamed storeLbls → separate revisionLabels + revisionAnnotations
• Clear function signatures showing labels vs annotations

✅ Bundle Metadata Location

• Kept in annotations (informational, no query use case, no length limits)

Why This Matters

• Consistency: Same labeling pattern across all OLM resources
• Maintainability: Clear, self-documenting code
• Safety: No breaking changes, no length restrictions
• Simplicity: Easier to review and merge

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	17e40e1
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/691d8d1e44d6ba000834894e
😎 Deploy Preview	https://deploy-preview-2344--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.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.30%. Comparing base (6ef62de) to head (17e40e1).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2344      +/-   ##
==========================================
+ Coverage   74.19%   74.30%   +0.10%     
==========================================
  Files          91       91              
  Lines        7228     7239      +11     
==========================================
+ Hits         5363     5379      +16     
+ Misses       1433     1429       -4     
+ Partials      432      431       -1     

Flag	Coverage Δ
e2e	44.29% <15.38%> (-0.11%)	⬇️
experimental-e2e	48.55% <84.61%> (+0.16%)	⬆️
unit	58.54% <92.30%> (+0.06%)	⬆️

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.

[joelanford]

Is there a use case for querying by any of the values that are currently in annotations? As far as I know, those annotations are there to serve as hints to the resolver (?), not to be queried.

If there aren't any specific query use cases yet, maybe we should hold off on changing this right now.

Annotations have fewer restrictions on their value, so I think we should only put values in labels when we know we need to query by them?

Maybe @pedjak would have a better rubric than I do on the label vs annotation debate in this case.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• internal/operator-controller/OWNERS

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

[Copilot]

Pull Request Overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

internal/operator-controller/applier/boxcutter_test.go:410

• [nitpick] Inconsistent field ordering in ObjectMeta initialization. Here Labels comes before Annotations, but in the test case at line 798-804, Annotations comes before Labels. Consider using consistent ordering throughout the file for better maintainability.

							Annotations: revisionAnnotations,
						},
						Spec: ocv1.ClusterExtensionRevisionSpec{
							Phases: []ocv1.ClusterExtensionRevisionPhase{
								{

---

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

[Copilot]

Pull Request Overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

---

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

[camilamacedo86]

Hi @joelanford

Thank you for your input.

Is there a use case for querying by any of the values that are currently in annotations? As far as I know, those annotations are there to serve as hints to the resolver (?), not to be queried.
If there aren't any specific query use cases yet, maybe we should hold off on changing this right now.
Annotations have fewer restrictions on their value, so I think we should only put values in labels when we know we need to query by them?
Maybe @pedjak would have a better rubric than I do on the label vs annotation debate in this case.

This PR is doing more than just moving the annotations to labels. I reverted the changes and kept the other fix. BUTI will open a new PR only for that so the smaller change doesn’t get blocked by this discussion.**
I won’t push strongly for this if the team disagrees.