Installing network policies when OSL is disabled

[elai-shalev]

This PR will introduce a fix to the backstage chart when installing Orchestrator with serverlessLogicOperator disabled, the network policies were not installed by the chart - but are still needed.
This is for the case that OSL already exists on the cluster, as happens in Upgrade scenarios.

This PR will fix the bug captured here.

Description of the change

Helm Condition change in charts/backstage/templates/network-policies.yaml

Checklist

• For each Chart updated, version bumped in the corresponding Chart.yaml according to Semantic Versioning.
• For each Chart updated, variables are documented in the values.yaml and added to the corresponding README.md. The pre-commit utility can be used to generate the necessary content. Use pre-commit run -a to apply changes. The pre-commit Workflow will do this automatically for you if needed.
• JSON Schema template updated and re-generated the raw schema via the pre-commit hook.
• Tests pass using the Chart Testing tool and the ct lint command.
• If you updated the orchestrator-infra chart, make sure the versions of the Knative CRDs are aligned with the versions of the CRDs installed by the OpenShift Serverless operators declared in the values.yaml file. See Installing Knative Eventing and Knative Serving CRDs for more details.

Summary by Sourcery

Ensure network policies are applied when the orchestrator is enabled even if the Serverless Logic Operator is disabled

Bug Fixes:

• Install network policies unconditionally when the orchestrator is enabled, fixing omission when Serverless Logic Operator is disabled

Enhancements:

• Bump backstage chart version to 4.5.7
• Update README badge to reflect new chart version

Documentation:

• Add explanatory comments in values.yaml for disabling serverless operator flags

[sonarqubecloud]

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

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Clarify the intent of the added comments in values.yaml for serverlessLogicOperator and serverlessOperator—currently they suggest disabling but leave the flags enabled, which may confuse users.
• Verify whether the network-policies template should also account for orchestrator.serverlessOperator.enabled to avoid unintended policy creation when both logic operators are disabled.

Prompt for AI Agents

Please address the comments from this code review:
## Overall Comments
- Clarify the intent of the added comments in values.yaml for serverlessLogicOperator and serverlessOperator—currently they suggest disabling but leave the flags enabled, which may confuse users.
- Verify whether the network-policies template should also account for orchestrator.serverlessOperator.enabled to avoid unintended policy creation when both logic operators are disabled.

## Individual Comments

### Comment 1
<location> `charts/backstage/values.yaml:360` </location>
<code_context>

 orchestrator:
   enabled: false
+  #  Disable Serverless Logic Operator if it already exists on the cluster
   serverlessLogicOperator:
     enabled: true
</code_context>

<issue_to_address>
Comment suggests disabling Serverless Logic Operator if it exists, but value remains enabled by default.

Please clarify whether the default should be 'enabled' or update the comment to accurately reflect the intended behavior.
</issue_to_address>

### Comment 2
<location> `charts/backstage/values.yaml:363` </location>
<code_context>
+  #  Disable Serverless Logic Operator if it already exists on the cluster
   serverlessLogicOperator:
     enabled: true
+  #  Disable Serverless Operator if it already exists on the cluster
   serverlessOperator:
     enabled: true
</code_context>

<issue_to_address>
Comment suggests disabling Serverless Operator if it exists, but value remains enabled by default.

Clarify whether users should manually disable the Serverless Operator, since the default remains enabled. Additional context or explicit instructions would help avoid confusion.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
  #  Disable Serverless Operator if it already exists on the cluster
  serverlessOperator:
    enabled: true
=======
  #  NOTE:
  #  If the Serverless Operator already exists on the cluster, set enabled: false below to avoid conflicts.
  #  Example:
  #    serverlessOperator:
  #      enabled: false
  serverlessOperator:
    enabled: true
>>>>>>> REPLACE

</suggested_fix>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[rm3l]

/lgtm

[rm3l]

@elai-shalev Same question again: does https://issues.redhat.com/browse/RHDHBUGS-2020 need to be backported to 1.7.1? Or can it wait until 1.8?

[elai-shalev]

@elai-shalev Same question again: does https://issues.redhat.com/browse/RHDHBUGS-2020 need to be backported to 1.7.1? Or can it wait until 1.8?

This also has an easy workaround, either by manually adding the NP or hacking the chart
So not required for 1.7.1, can wait for 1.8