PR images are available:

1. https://quay.io/rhdh-community/operator:0.10.0-pr-2733-3ef8b9f
2. https://quay.io/rhdh-community/operator-bundle:0.10.0-pr-2733-3ef8b9f
3. https://quay.io/rhdh-community/operator-catalog:0.10.0-pr-2733-3ef8b9f

PR images are available:

1. https://quay.io/rhdh-community/operator:0.10.0-pr-2733-d3dd75e
2. https://quay.io/rhdh-community/operator-bundle:0.10.0-pr-2733-d3dd75e
3. https://quay.io/rhdh-community/operator-catalog:0.10.0-pr-2733-d3dd75e

Hmm.., it might be confusing to see that some resources are still there when the corresponding feature is purposely toggled from enabled to disabled. For example, I first create a Backstage CR on OCP (so with a Route created by default), then I set spec.application.route.enabled: false in the CR, and now the Route object is still present. Maybe the Operator could add some uniquely identifiable labels on the resources it creates and manages, and only try to delete those to avoid conflict with user-created resources? Or (thinking out loud) maybe just refuse to reconcile if there are conflicting resources that it does not manage, and thus avoid touching those?

Let's just document it for clarity and keep simple until we really need to make it complex.
Those resources, with specific names, are "special", operator manages it if certain feature is enabled and ignores otherwise.

PR images are available:

1. https://quay.io/rhdh-community/operator:0.10.0-pr-2733-3ce8528
2. https://quay.io/rhdh-community/operator-bundle:0.10.0-pr-2733-3ce8528
3. https://quay.io/rhdh-community/operator-catalog:0.10.0-pr-2733-3ce8528

Hmm.., it might be confusing to see that some resources are still there when the corresponding feature is purposely toggled from enabled to disabled. For example, I first create a Backstage CR on OCP (so with a Route created by default), then I set spec.application.route.enabled: false in the CR, and now the Route object is still present. Maybe the Operator could add some uniquely identifiable labels on the resources it creates and manages, and only try to delete those to avoid conflict with user-created resources? Or (thinking out loud) maybe just refuse to reconcile if there are conflicting resources that it does not manage, and thus avoid touching those?

Let's just document it for clarity and keep simple until we really need to make it complex. Those resources, with specific names, are "special", operator manages it if certain feature is enabled and ignores otherwise.

This would be kinda breaking change then, I guess.
But overall, I think that even with documentation, just leaving them as is might end up creating more confusion with orphaned resources that might still consume cluster resources. The example with the Route would be particularly confusing IMO as the route is still active (can accept external traffic) but is no longer managed by the Operator.
Since the operator already sets owner reference on the resources it creates, would it make sense to "just" check with metav1.IsControlledBy before deleting? I feel like this would be small targeted changed compared to the current PR which, IMHO, would be a behavioral change that might end up causing more confusion (in 1.10).

Hmm.., it might be confusing to see that some resources are still there when the corresponding feature is purposely toggled from enabled to disabled. For example, I first create a Backstage CR on OCP (so with a Route created by default), then I set spec.application.route.enabled: false in the CR, and now the Route object is still present. Maybe the Operator could add some uniquely identifiable labels on the resources it creates and manages, and only try to delete those to avoid conflict with user-created resources? Or (thinking out loud) maybe just refuse to reconcile if there are conflicting resources that it does not manage, and thus avoid touching those?

Let's just document it for clarity and keep simple until we really need to make it complex. Those resources, with specific names, are "special", operator manages it if certain feature is enabled and ignores otherwise.

This would be kinda breaking change then, I guess. But overall, I think that even with documentation, just leaving them as is might end up creating more confusion with orphaned resources that might still consume cluster resources. The example with the Route would be particularly confusing IMO as the route is still active (can accept external traffic) but is no longer managed by the Operator. Since the operator already sets owner reference on the resources it creates, would it make sense to "just" check with metav1.IsControlledBy before deleting? I feel like this would be small targeted changed compared to the current PR which, IMHO, would be a behavioral change that might end up causing more confusion (in 1.10).

As discussed today, let's document this here (and also consider mentioning this in the official product docs).

/cherry-pick release-1.10

@rm3l: once the present PR merges, I will cherry-pick it on top of release-1.10 in a new PR and assign it to you.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.05%. Comparing base (0e1d1db) to head (056699b).

@@            Coverage Diff             @@
##             main    #2733      +/-   ##
==========================================
- Coverage   61.18%   61.05%   -0.13%     
==========================================
  Files          37       37              
  Lines        2128     2098      -30     
==========================================
- Hits         1302     1281      -21     
+ Misses        692      683       -9     
  Partials      134      134              

PR images are available:

1. https://quay.io/rhdh-community/operator:0.11.0-pr-2733-056699b
2. https://quay.io/rhdh-community/operator-bundle:0.11.0-pr-2733-056699b
3. https://quay.io/rhdh-community/operator-catalog:0.11.0-pr-2733-056699b