🐛 Fix an unclear validation error when configuring watchNamespace on an operator restricted to AllNamespaces mode.

[camilamacedo86]

Summary of Changes

When a ClusterExtension with watchNamespace config is applied to an AllNamespaces-only, the error message has been improved to be more descriptive.

Before vs After

Scenario: User tries to configure watchNamespace on AllNamespaces-only operator

BEFORE:

invalid ClusterExtension configuration: invalid configuration: unknown field "watchNamespace"

NOW:

invalid ClusterExtension configuration: invalid configuration: watchNamespace configuration is not supported when the content only supports "AllNamespaces" install mode

Motivation

https://issues.redhat.com//browse/OCPBUGS-63611

[netlify]

✅ Deploy Preview for olmv1 ready!

Name	Link
🔨 Latest commit	f85c707
🔍 Latest deploy log	https://app.netlify.com/projects/olmv1/deploys/691e0aa01f374d00080420de
😎 Deploy Preview	https://deploy-preview-2347--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]

Pull Request Overview

This PR improves error messaging when users attempt to configure watchNamespace on operators that only support AllNamespaces install mode. The error message has been enhanced from a generic "unknown field" message to a more descriptive explanation indicating that only AllNamespaces install mode is supported.

Key Changes:

• Enhanced error message formatting in config validation to provide context-specific feedback for watchNamespace field rejection
• Updated test expectations to reflect the new error message
• Removed MultiNamespace-related test cases, as this install mode is not supported by the validation system

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
internal/operator-controller/config/config.go	Added special case handling in error formatting to provide descriptive message when watchNamespace is rejected
internal/operator-controller/config/config_test.go	Updated test expectations for new error message and removed unsupported MultiNamespace test cases

---

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.29%. Comparing base (03eb884) to head (f85c707).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2347      +/-   ##
==========================================
+ Coverage   74.23%   74.29%   +0.05%     
==========================================
  Files          91       91              
  Lines        7239     7255      +16     
==========================================
+ Hits         5374     5390      +16     
  Misses       1433     1433              
  Partials      432      432              

Flag	Coverage Δ
e2e	44.21% <0.00%> (-0.04%)	⬇️
experimental-e2e	48.60% <82.35%> (+0.12%)	⬆️
unit	58.48% <29.41%> (-0.07%)	⬇️

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

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

---

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

[pedjak]

/lgtm

[pedjak]

not sure if this qualifies as a bug fix, perhaps is just a 🌱 ?

[camilamacedo86]

Hi @pedjak,

Thank you for review 🥇

not sure if this qualifies as a bug fix, perhaps is just a 🌱 ?

This is a bug.

Before: The message shown to the end user was unclear and unhelpful.
Now: The fix updates the message the end user sees, improving clarity.
Because it changes end-user behavior/output, it should be marked as a bug fix
That is why it should fix a OCPBUG: https://issues.redhat.com/browse/OCPBUGS-63611

When to use 🌱

Use the 🌱 label ONLY when the change has zero impact on end users. This includes:

• No new or modified behavior
• No new or changed error messages
• No new logs
• No new labels, fields, or resources
• No visible changes in how the system behaves or is used

In other words, 🌱 is reserved strictly for internal, non-functional updates such as
refactoring, cleanup, infra changes or code organisation. If an end user could notice the change
in any way, the 🌱 label should NOT be used.

[rashmigottipati]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pedjak, rashmigottipati
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

[openshift-ci]

New changes are detected. LGTM label has been removed.

[camilamacedo86]

/hold cancel

@perdasilva @rashmigottipati @tmshort

Sorry about my slip-up earlier. Everything is all set now! Thanks for the support

[Copilot]

Pull Request Overview

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

---

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

[tmshort]

The headline and PR/commit summary do not patch what the PR now does, which is to add a new install mode.

[joelanford]

@perdasilva can correct me if I am wrong, but my understanding of the overall intended progression of the registry+v1 configuration schema is that we will:

1. Implement support for subscription.spec.config
2. Shift to generating (and validating with) JSON Schema for the combined watchNamespace and subscription.spec.config configuration based on the shape of the registry+v1 bundle.
3. Be positioned to handle other formats (e.g. helm charts) that already ship with JSON schemas of their configuration.

With that in mind (and if that is still true), I don't think we should be spending cycles implementing and reviewing the current validation implementation. The focus (I think) is on the order of operations above.

[joelanford]

Dropped a comment in the bug as well to try to explain our stance: https://issues.redhat.com/browse/OCPBUGS-63611?focusedId=28504231&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-28504231

Design decision doc also mentions this descoping aspect of OLMv1 near the very top: https://operator-framework.github.io/operator-controller/project/olmv1_design_decisions/#watched-namespaces-cannot-be-configured-in-a-first-class-api

[camilamacedo86]

Hi @joelanford

Regards your comment: #2347 (comment)

@perdasilva can correct me if I am wrong, but my understanding of the overall intended progression of the registry+v1 configuration schema is that we will:

Yes, that is ALL true but we either have the option to create a customize validations and messages if we need to do so. You can check the design in: #2316

But I completely agree that we can’t create a custom message or behavior for every single flag and option, as that would lead to infinite maintenance cycles. I appreciate your comment in the JIRA, and I’m closing this one as won’t do.