feat(orchestrator-infra): add OLM v1 ClusterExtension install path (RHIDP-14789)

[Fortune-Ndlovu]

Summary

• Add olmVersion (v0 | v1 | auto, default v0) to orchestrator-infra
• Render OLM v1 ClusterExtension resources (with installer ServiceAccount + ClusterRoleBinding) for OpenShift Serverless and Serverless Logic operators
• Keep existing OLM v0 Subscription path when olmVersion=v0 or when auto selects v0
• Install Knative CRDs from files/ on the v0 path only; skip Knative CRs on the v1 path
• Update helm tests, README, values schema, and CI values

Scope

Per review discussion on RHIDP-14789, this PR is scoped to orchestrator-infra only. OLM v1 work for orchestrator-software-templates-infra is deferred.

Related

• https://redhat.atlassian.net/browse/RHIDP-14789

How to test

Prerequisites

• OpenShift 4.22+ cluster with OLM v1 (clusterextensions.olm.operatorframework.io CRD present)
• cluster-admin access
• helm 3 and oc CLI installed
• Logged in: oc login <api-url> -u <user>

0. Get the chart branch

git clone https://github.com/Fortune-Ndlovu/rhdh-chart.git
cd rhdh-chart
git checkout feat/RHIDP-14789-orchestrator-infra-olm-v1

Optional local render check:

helm template test-v0 ./charts/orchestrator-infra --set olmVersion=v0 | rg "^kind:" | sort | uniq -c
helm template test-v1 ./charts/orchestrator-infra --set olmVersion=v1 | rg "^kind:" | sort | uniq -c

Expected:

• v0: Subscription, OperatorGroup, CustomResourceDefinition, KnativeServing, KnativeEventing
• v1: ClusterExtension, installer ServiceAccount, ClusterRoleBinding (no Subscription, no OperatorGroup, no Knative CRs)

Verify OLM v1 is available on the cluster:

oc get crd clusterextensions.olm.operatorframework.io
oc get clustercatalog

---

1. Test OLM v0 path (default, production path)

helm upgrade --install my-orchestrator-infra ./charts/orchestrator-infra \
  --namespace default \
  --set olmVersion=v0 \
  --wait --timeout 5m

Verify rendered resources (no ClusterExtensions):

helm get manifest my-orchestrator-infra | rg "^kind:" | sort | uniq -c
oc get subscription.operators.coreos.com -n openshift-serverless serverless-operator
oc get subscription.operators.coreos.com -n openshift-serverless-logic logic-operator
oc get operatorgroup.operators.coreos.com -n openshift-serverless
oc get operatorgroup.operators.coreos.com -n openshift-serverless-logic
oc get clusterextension serverless-operator logic-operator 2>&1   # should be NotFound

Approve InstallPlans (chart default is installPlanApproval: Manual):

OS_PLAN=$(oc get installplan.operators.coreos.com -n openshift-serverless \
  --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[0].metadata.name}')
oc patch installplan.operators.coreos.com "$OS_PLAN" -n openshift-serverless \
  --type merge --patch '{"spec":{"approved":true}}'

OSL_PLAN=$(oc get installplan.operators.coreos.com -n openshift-serverless-logic \
  --sort-by=.metadata.creationTimestamp -o jsonpath='{.items[0].metadata.name}')
oc patch installplan.operators.coreos.com "$OSL_PLAN" -n openshift-serverless-logic \
  --type merge --patch '{"spec":{"approved":true}}'

Wait for operator CSVs:

oc get csv.operators.coreos.com -n openshift-serverless serverless-operator -w
oc get csv.operators.coreos.com -n openshift-serverless-logic logic-operator -w

Wait for Knative instances (created by the chart on v0):

oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -w
oc get knativeeventing.operator.knative.dev knative-eventing -n knative-eventing -w

Run helm test:

helm test my-orchestrator-infra --namespace default

---

2. Clean up before OLM v1 test

A prior v0 install leaves helm-managed Knative CRDs that block OLM v1 bundle install. Remove everything before testing v1:

helm uninstall my-orchestrator-infra --namespace default

oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless --ignore-not-found
oc delete subscription.operators.coreos.com logic-operator -n openshift-serverless-logic --ignore-not-found

# Wait for operator namespaces to finish terminating
oc get ns openshift-serverless openshift-serverless-logic knative-serving knative-eventing

# Remove helm-managed Knative CRDs (required for a clean v1 test)
oc delete crd knativeservings.operator.knative.dev knativeeventings.operator.knative.dev --ignore-not-found

# Confirm no leftover ClusterExtensions from a prior v1 attempt
oc delete clusterextension serverless-operator logic-operator --ignore-not-found
oc delete clusterrolebinding serverless-operator-installer-binding logic-operator-installer-binding --ignore-not-found

---

3. Test OLM v1 path

helm upgrade --install my-orchestrator-infra-v1 ./charts/orchestrator-infra \
  --namespace default \
  --set olmVersion=v1 \
  --wait --timeout 5m

Verify rendered resources (ClusterExtensions, no Subscriptions):

helm get manifest my-orchestrator-infra-v1 | rg "^kind:" | sort | uniq -c
oc get clusterextension serverless-operator logic-operator
oc get subscription.operators.coreos.com -A | rg 'serverless|logic'   # should be empty
oc get operatorgroup.operators.coreos.com -n openshift-serverless -n openshift-serverless-logic 2>&1
oc get sa -n openshift-serverless serverless-operator-installer
oc get sa -n openshift-serverless-logic serverless-logic-operator-installer
oc get clusterrolebinding serverless-operator-installer-binding logic-operator-installer-binding

Monitor ClusterExtension install:

watch oc get clusterextension serverless-operator logic-operator \
  -o custom-columns=NAME:.metadata.name,BUNDLE:.status.install.bundle.name,INSTALLED:.status.conditions[?(@.type==\"Installed\")].status,REASON:.status.conditions[?(@.type==\"Installed\")].reason

If install fails, inspect conditions:

oc describe clusterextension serverless-operator
oc describe clusterextension logic-operator

Run helm test (checks ClusterExtension resources exist):

helm test my-orchestrator-infra-v1 --namespace default

After both ClusterExtensions report Installed=True, create Knative instances manually (not created by the chart on v1):

cat <<'YAML' | oc apply -f -
apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  controller-custom-certs:
    name: ""
    type: ""
  registry: {}
---
apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  registry: {}
YAML

oc get knativeserving.operator.knative.dev knative-serving -n knative-serving -w
oc get knativeeventing.operator.knative.dev knative-eventing -n knative-eventing -w

---

4. Test olmVersion=auto (optional)

On a cluster with the OLM v1 CRD, auto should render ClusterExtensions:

helm template test-auto ./charts/orchestrator-infra --set olmVersion=auto | rg "kind: ClusterExtension"

---

5. Final cleanup

helm uninstall my-orchestrator-infra-v1 --namespace default
oc delete clusterextension serverless-operator logic-operator --ignore-not-found
oc delete clusterrolebinding serverless-operator-installer-binding logic-operator-installer-binding --ignore-not-found
oc delete knativeserving.operator.knative.dev knative-serving -n knative-serving --ignore-not-found
oc delete knativeeventing.operator.knative.dev knative-eventing -n knative-eventing --ignore-not-found

[rhdh-qodo-merge]

PR Summary by Qodo

Add OLM v1 ClusterExtension path to orchestrator infrastructure

✨ Enhancement 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add selectable OLM v0, v1, and auto installation paths for Serverless operators.
• Render ClusterExtensions with installer RBAC while preserving Subscription-based installations.
• Defer Knative custom resources on v1 and validate both paths through Helm tests.

Diagram

graph TD
  A["Helm Values"] --> B{"Resolve OLM Version"}
  B -->|resolved v0| C["OperatorGroups"] --> D["Subscriptions"] --> E["Knative CRs"]
  B -->|resolved v1| F["Installer RBAC"] --> G["ClusterExtensions"]
  D --> H["Helm Tests"]
  G --> H

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Separate OLM v0 and v1 charts

• ➕ Simplifies each chart's templates and lifecycle semantics
• ➕ Avoids conditional rendering across incompatible OLM APIs
• ➖ Duplicates operator configuration, documentation, and maintenance
• ➖ Complicates migration and fragments the chart's public interface

2. Create Knative resources through a post-install hook

• ➕ Could complete OLM v1 and Knative provisioning in one Helm operation
• ➕ Avoids requiring users to create Knative resources separately
• ➖ Requires readiness polling and timeout handling inside Helm hooks
• ➖ Introduces fragile lifecycle behavior when operator CRDs are delayed or installation fails

3. Use least-privilege installer roles

• ➕ Reduces privileges compared with binding installer accounts to cluster-admin
• ➕ Better aligns with production security policies
• ➖ Required permissions may change between operator bundle versions
• ➖ Incomplete permissions can cause difficult-to-diagnose ClusterExtension failures

Recommendation: The dual-path chart is the best approach because it preserves the stable OLM v0 default while enabling migration to OLM v1 without splitting configuration across charts. Deferring Knative custom resources avoids CRD readiness races; least-privilege installer RBAC should be considered later when stable permission requirements are available.

Files changed (18) +428 / -40

Enhancement (8) +184 / -21

_helpers.tplAdd OLM resolution and resource ownership helpers +49/-5

Add OLM resolution and resource ownership helpers

• Resolves explicit or automatic OLM versions, detects unmanaged ClusterExtensions, and extracts semantic versions from CSV names. Resource ownership now requires both the Helm release name and namespace.

charts/orchestrator-infra/templates/_helpers.tpl

clusterextension.yamlRender the Serverless Logic ClusterExtension installation +57/-0

Render the Serverless Logic ClusterExtension installation

• Adds an OLM v1 ClusterExtension, installer service account, and cluster-admin binding for the Serverless Logic operator. Rendering is suppressed when conflicting unmanaged OLM resources exist.

charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml

operator-group.yamlRestrict the Serverless Logic OperatorGroup to OLM v0 +1/-1

Restrict the Serverless Logic OperatorGroup to OLM v0

• Prevents the classic OperatorGroup from rendering when the chart resolves to OLM v1.

charts/orchestrator-infra/templates/serverless-logic/operator-group.yaml

subscription.yamlGate the Serverless Logic Subscription to OLM v0 +7/-4

Gate the Serverless Logic Subscription to OLM v0

• Renders the Subscription only for OLM v0 and avoids conflicts with existing unmanaged Subscriptions or ClusterExtensions.

charts/orchestrator-infra/templates/serverless-logic/subscription.yaml

clusterextension.yamlRender the Serverless ClusterExtension installation +56/-0

Render the Serverless ClusterExtension installation

• Adds an OLM v1 ClusterExtension, installer service account, and cluster-admin binding for OpenShift Serverless. The resource uses the configured ClusterCatalog selector and avoids unmanaged OLM resources.

charts/orchestrator-infra/templates/serverless/clusterextension.yaml

knatives.yamlDefer Knative custom resources on OLM v1 +6/-6

Defer Knative custom resources on OLM v1

• Skips KnativeEventing and KnativeServing creation on the v1 path so operator CRDs can be installed first. Namespace and resource ownership checks now include the Helm release namespace.

charts/orchestrator-infra/templates/serverless/knatives.yaml

operator-group.yamlRestrict the Serverless OperatorGroup to OLM v0 +1/-1

Restrict the Serverless OperatorGroup to OLM v0

• Prevents the classic OperatorGroup from rendering for OLM v1 installations.

charts/orchestrator-infra/templates/serverless/operator-group.yaml

subscription.yamlGate the Serverless Subscription to OLM v0 +7/-4

Gate the Serverless Subscription to OLM v0

• Renders the Subscription only on the v0 path and prevents collisions with unmanaged Subscriptions or ClusterExtensions.

charts/orchestrator-infra/templates/serverless/subscription.yaml

Bug fix (3) +3 / -3

NOTES.txtInclude release namespace in ownership detection +1/-1

Include release namespace in ownership detection

• Passes the Helm release namespace when checking whether an existing Serverless subscription belongs to the current release.

charts/orchestrator-infra/templates/NOTES.txt

namespace.yamlStrengthen Serverless Logic namespace ownership checks +1/-1

Strengthen Serverless Logic namespace ownership checks

• Includes the Helm release namespace when determining whether the operator namespace is managed by this release.

charts/orchestrator-infra/templates/serverless-logic/namespace.yaml

namespace.yamlStrengthen Serverless namespace ownership checks +1/-1

Strengthen Serverless namespace ownership checks

• Includes the Helm release namespace when determining whether the operator namespace belongs to this release.

charts/orchestrator-infra/templates/serverless/namespace.yaml

Tests (1) +41 / -3

infra-test.yamlTest the resolved OLM installation path +41/-3

Test the resolved OLM installation path

• Adds test RBAC for cluster-scoped ClusterExtensions and switches assertions between ClusterExtensions and Subscriptions. It also corrects operator enablement and value references in the existing checks.

charts/orchestrator-infra/templates/tests/infra-test.yaml

Documentation (2) +40 / -12

README.mdDocument OLM v0 and v1 installation modes +23/-7

Document OLM v0 and v1 installation modes

• Updates generated chart metadata and documents v0, v1, and automatic selection. Adds migration guidance for Knative resources and the new configuration values.

charts/orchestrator-infra/README.md

README.md.gotmplAdd OLM mode guidance to the README template +17/-5

Add OLM mode guidance to the README template

• Adds the source documentation for selecting OLM versions and handling Knative resources during v1 migration.

charts/orchestrator-infra/README.md.gotmpl

Other (4) +160 / -1

Chart.yamlBump orchestrator infrastructure chart to 0.6.2 +1/-1

Bump orchestrator infrastructure chart to 0.6.2

• Increments the chart version to publish the new OLM installation capability.

charts/orchestrator-infra/Chart.yaml

values.schema.jsonPublish schema for OLM v1 settings +73/-0

Publish schema for OLM v1 settings

• Defines accepted OLM versions, the ClusterCatalog selector, and installer service account names in the generated values schema.

charts/orchestrator-infra/values.schema.json

values.schema.tmpl.jsonDefine source schema for OLM v1 settings +69/-0

Define source schema for OLM v1 settings

• Adds schema definitions for OLM mode selection, catalog filtering, and per-operator installer service accounts.

charts/orchestrator-infra/values.schema.tmpl.json

values.yamlAdd default OLM mode and ClusterExtension settings +17/-0

Add default OLM mode and ClusterExtension settings

• Defaults installations to OLM v0 and configures the Red Hat ClusterCatalog selector. Adds installer service account names for both Serverless operators.

charts/orchestrator-infra/values.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

⚠️ 1 lower-priority finding omitted to fit the comment size limit; re-run the review or view the findings in the Qodo portal.

1. Fresh default installs fail validation ⊘ Outdated 🐞 Bug ≡ Correctness

Description

knative-crds.yaml emits missing definitions only as pre-install hooks, while knatives.yaml
simultaneously leaves KnativeServing and KnativeEventing in the ordinary release manifest. On a
fresh v0/default cluster without these APIs, Helm builds and maps the ordinary manifest before
executing pre-install hooks, so installation stops on the unknown Knative kinds and neither
definition is created.

Code

charts/orchestrator-infra/files/knative-serving/knative-serving-crd.yaml[20]

+    "helm.sh/hook": pre-install

Relevance

●●● Strong

Fresh installs can fail before pre-install hooks create CRDs; accepted history supports fixing
hook-based deployment failures.

PR-#407
PR-#289

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both definition files are marked only as pre-install hooks, and the new template renders them only
when lookup reports that they are missing. The regular v0 template still renders KnativeEventing
and KnativeServing, requiring API mappings that do not exist while Helm initially builds the
release manifest.

charts/orchestrator-infra/files/knative-serving/knative-serving-crd.yaml[18-22]
charts/orchestrator-infra/files/knative-eventing/knative-eventing-crd.yaml[18-22]
charts/orchestrator-infra/templates/serverless/knative-crds.yaml[1-9]
charts/orchestrator-infra/templates/serverless/knatives.yaml[28-54]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Knative definitions are now pre-install hooks, but their custom resources remain in Helm's ordinary manifest. On a fresh v0 installation, Helm cannot map those custom resource kinds before executing the hooks.

## Fix Focus Areas
- charts/orchestrator-infra/files/knative-serving/knative-serving-crd.yaml[20-22]
- charts/orchestrator-infra/files/knative-eventing/knative-eventing-crd.yaml[20-22]
- charts/orchestrator-infra/templates/serverless/knative-crds.yaml[1-9]
- charts/orchestrator-infra/templates/serverless/knatives.yaml[28-54]

## Recommended Fix
Keep the conditional v0 CRD provisioning, but remove the Knative custom resources from the ordinary release manifest and create them through a post-install hook job after waiting for both definitions to become Established. Add a fresh-cluster installation test where neither Knative definition is pre-created.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Upgrades remove required Knative instances ⊘ Outdated 🔗 Cross-repo conflict ≡ Correctness

Description

knative-v1-post-install.yaml marks the service account, RBAC, ConfigMap, and provisioning Job only
as post-install, so Helm does not run the Job during the documented v0-to-v1 upgrade. When the v1
templates omit and remove the previously managed Knative instances, the inactive replacement hook
leaves operator-managed Orchestrator installations without the required Knative Serving and Eventing
prerequisites.

Code

charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[11]

+    helm.sh/hook: post-install

Relevance

●●● Strong

Upgrade-path resource loss is a concrete lifecycle bug contradicting documented v0-to-v1 upgrades.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The chart README explicitly documents upgrading an existing v0 installation to v1, while every
provisioning resource is restricted to post-install and the only Knative creation commands are
contained in that Job. Because the normal v1 templates suppress the previously Helm-managed
instances, the upgrade removes them without recreating them; the operator repository identifies
Knative Serving and Eventing as prerequisites and directs operator-managed installations to this
chart, confirming that this cross-repository installation path is left incomplete.

charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[5-13]
charts/orchestrator-infra/README.md[120-124]
charts/orchestrator-infra/README.md[120-120]
charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[75-78]
charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[117-128]
charts/orchestrator-infra/templates/serverless/knatives.yaml[28-52]
External repo: redhat-developer/rhdh-operator, docs/orchestrator.md [3-10]
External repo: redhat-developer/rhdh-operator, docs/orchestrator.md [63-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The OLM v1 Knative provisioning hook runs only after fresh installations, although the chart documents and supports upgrading an existing v0 release to v1. During that upgrade, Helm removes the old manifest-managed Knative instances but does not execute the hook that recreates them.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[1-133]
- charts/orchestrator-infra/README.md[120-120]

## Recommended Fix
Add `post-upgrade` alongside `post-install` to every hook resource and the Job, including the service account, RBAC, and ConfigMap. Preserve the existing hook weights so the supporting resources are available before the Job starts, and add an upgrade-path test that changes `olmVersion` from `v0` to `v1` and verifies that both Knative instances exist afterward.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Existing Knative data is deleted ✓ Resolved 🐞 Bug ≡ Correctness

Description

The moved CRDs are now pre-install hooks whose existing before-hook-creation policy deletes
same-named resources before creating the hook manifests. Installing the v0 chart on a cluster where
another operator installation already owns these CRDs can therefore delete the definitions and all
custom resources stored under them before replacing the definitions.

Code

charts/orchestrator-infra/files/knative-eventing/knative-eventing-crd.yaml[R20-21]

+    "helm.sh/hook": pre-install,pre-delete
+    "helm.sh/hook-weight": "-20"

Relevance

●●● Strong

Destructive CRD hook behavior is a clear correctness risk; no rejection precedent was found.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new template renders both CRD files as hooks on every enabled v0 installation, and each file
combines pre-install with before-hook-creation; the rendering condition does not check whether
either CRD is externally owned.

charts/orchestrator-infra/templates/serverless/knative-crds.yaml[1-5]
charts/orchestrator-infra/files/knative-eventing/knative-eventing-crd.yaml[17-22]
charts/orchestrator-infra/files/knative-serving/knative-serving-crd.yaml[17-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Rendering the CRDs as pre-install hooks activates `before-hook-creation`, which is destructive when matching CRDs already exist. Deleting a CRD also deletes its custom resources, so an installation can erase an existing Knative deployment.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/knative-crds.yaml[1-5]
- charts/orchestrator-infra/files/knative-eventing/knative-eventing-crd.yaml[20-22]
- charts/orchestrator-infra/files/knative-serving/knative-serving-crd.yaml[20-22]

## Recommended Fix
Replace the direct CRD hooks with an idempotent pre-install mechanism that creates missing CRDs or safely applies compatible updates without deleting existing definitions. Ensure an externally installed CRD is never removed merely to satisfy hook creation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View high (3)

4. Version-one installs retain conflicting custom definitions 🐞 Bug ≡ Correctness

Description

knatives.yaml gates only the KnativeEventing and KnativeServing instances on olmVersion, while
their static definitions remain under Helm’s unconditional crds/ directory and the
ClusterExtension disables CRD upgrade-safety enforcement. On a fresh v1 installation, Helm processes
those chart-supplied definitions before templates and before the operator bundle, so selecting v1
neither avoids nor surfaces the overlap that the upgrade guidance tells users to remove.

Code

charts/orchestrator-infra/templates/serverless/knatives.yaml[R28-29]

+{{- $unmanagedKnativeEventingExists := include "unmanaged-resource-exists" (list "operator.knative.dev/v1beta1" "KnativeEventing" "knative-eventing" "knative-eventing" .Release.Name .Release.Namespace .Capabilities.APIVersions) }}
+{{- if and (eq $unmanagedKnativeEventingExists "false") (ne (include "olm-version" .) "v1") }}

Relevance

●●● Strong

Directly conflicts with the PR’s stated v1 goal of avoiding bundled CRD collisions; unconditional
crds remain installed.

PR-#289

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The cited template condition applies only to the Knative custom resource instances, while the two
cited files are actual CustomResourceDefinitions under Helm’s special crds/ directory, which the
documentation says is installed on every installation and which Helm processes without evaluating
the olmVersion template condition. The same documentation instructs v1 users to remove these
definitions, and the ClusterExtension configuration sets CRD upgrade-safety enforcement to None,
confirming that the remaining overlap will not be rejected by its preflight.

charts/orchestrator-infra/templates/serverless/knatives.yaml[28-41]
charts/orchestrator-infra/crds/knative-eventing/knative-eventing-crd.yaml[16-27]
charts/orchestrator-infra/crds/knative-serving/knative-serving-crd.yaml[16-27]
charts/orchestrator-infra/templates/serverless/clusterextension.yaml[40-43]
charts/orchestrator-infra/README.md[121-125]
charts/orchestrator-infra/README.md.gotmpl[92-96]
charts/orchestrator-infra/crds/knative-eventing/knative-eventing-crd.yaml[15-22]
charts/orchestrator-infra/crds/knative-serving/knative-serving-crd.yaml[15-22]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The version-one path suppresses only the Knative custom resources, not the static Knative custom resource definitions under Helm’s special `crds/` directory. Helm installs those definitions before evaluating template conditions, so a fresh v1 installation still creates resources that should be left for the ClusterExtension operator bundle to manage.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/knatives.yaml[28-29]
- charts/orchestrator-infra/README.md.gotmpl[92-96]
- charts/orchestrator-infra/crds/knative-eventing/knative-eventing-crd.yaml[15-22]
- charts/orchestrator-infra/crds/knative-serving/knative-serving-crd.yaml[15-22]

## Recommended Fix
Move the bundled Knative custom resource definitions out of the unconditional `crds/` directory and install them through a v0-only mechanism that preserves the required ordering, such as gated pre-install hook templates or a separately gated chart component. Ensure `olmVersion=v1` renders and installs neither the bundled definitions nor the Knative custom resources, leaving their lifecycle to the ClusterExtension bundle; update the generated documentation to describe this conditional behavior and add a render test proving that v1 output contains no Knative CRDs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Version-one install checks always fail ⊘ Outdated 🐞 Bug ≡ Correctness

Description

The new CI values force olmVersion: v1, causing chart-testing to submit ClusterExtension
resources even though the test-cluster setup installs only classic OLM v0.31.0. When ct install
processes this values file, the cluster has no provisioned OLM v1 API or controller to accept those
resources.

Code

charts/orchestrator-infra/ci/upstream-olm-v1-values.yaml[1]

+olmVersion: v1

Relevance

●●● Strong

CI explicitly installs OLM v0, so forcing v1 makes the added chart-testing scenario fail.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The added values file explicitly selects v1, while both new operator templates render the v1
ClusterExtension kind. The repository's test action installs the v0.31.0 classic OLM release and
then runs ct install, with no intervening setup for the v1 API.

charts/orchestrator-infra/ci/upstream-olm-v1-values.yaml[1-14]
charts/orchestrator-infra/templates/serverless/clusterextension.yaml[31-32]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[31-32]
.github/actions/test-charts/action.yml[171-180]
.github/actions/test-charts/action.yml[272-364]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new chart-testing values force OLM v1, but the shared test-cluster setup provisions only classic OLM, so installation cannot create the rendered ClusterExtension resources.

## Fix Focus Areas
- charts/orchestrator-infra/ci/upstream-olm-v1-values.yaml[1-14]
- .github/actions/test-charts/action.yml[171-180]
- .github/actions/test-charts/action.yml[272-364]

## Recommended Fix
Provision the OLM v1 ClusterExtension CRD and its controller before chart-testing runs this values scenario, and wait until that API is available before invoking `ct install`. If the shared cluster cannot support OLM v1, move this scenario to a dedicated environment that does rather than including it among generic chart-testing values.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. Mode changes leave two operator installers ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new v1 templates only test for an unmanaged ClusterExtension, while the v0 templates only test
for an unmanaged Subscription. Changing modes with an externally managed resource of the other
kind leaves it in place and renders the new kind for the same package and target namespace.

Code

charts/orchestrator-infra/templates/serverless/clusterextension.yaml[R4-5]

+{{- $unmanagedClusterExtensionExists := include "unmanaged-clusterextension-exists" (list $packageName .Release.Name .Capabilities.APIVersions) -}}
+{{- if and (eq (include "olm-version" .) "v1") (eq $unmanagedClusterExtensionExists "false") .Values.serverlessOperator.enabled }}

Relevance

●● Moderate

Mode-transition cleanup is a valid semantic concern, but no close historical precedent confirms team
acceptance.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new helper performs only a cluster-scoped ClusterExtension lookup, and the pre-existing helper
performs only the supplied resource lookup while preserving resources without this release's
annotation. Each template gates creation solely on its own kind, so neither mode detects an
unmanaged installer created by the other API.

charts/orchestrator-infra/templates/serverless/clusterextension.yaml[1-5]
charts/orchestrator-infra/templates/serverless/subscription.yaml[1-9]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[1-5]
charts/orchestrator-infra/templates/serverless-logic/subscription.yaml[1-9]
charts/orchestrator-infra/templates/_helpers.tpl[52-70]
charts/orchestrator-infra/templates/_helpers.tpl[11-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Switching between OLM v0 and v1 can render a new installer while an unmanaged installer of the opposite kind remains for the same operator. This creates competing OLM resources instead of preserving the chart's existing unmanaged-resource protection.

### Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/clusterextension.yaml[4-5]
- charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[4-5]
- charts/orchestrator-infra/templates/serverless/subscription.yaml[2-2]
- charts/orchestrator-infra/templates/serverless-logic/subscription.yaml[2-2]

### Recommended Fix
Before rendering either installer kind, check for both the namespaced Subscription and the cluster-scoped ClusterExtension. Do not render a resource when an unmanaged opposite-kind installer exists; alternatively fail rendering with a clear migration error. Apply the same behavior to Serverless and Serverless Logic.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. Upgrade regressions bypass CI ⊘ Outdated 🐞 Bug ☼ Reliability ⭐ New

Description

The new upgrade step exits successfully whenever the ClusterExtension API is absent, but this action
always creates a fresh KinD cluster and installs only legacy OLM version 0.31.0. Every invocation
therefore returns before either Helm command runs, leaving the new version-zero-to-version-one
transition untested.

Code

.github/actions/test-charts/action.yml[R369-372]

+        if ! kubectl api-resources -o name | grep -q '^clusterextensions\.olm\.operatorframework\.io$'; then
+          echo "ClusterExtension API not available; skipping OLM v0 to v1 upgrade test"
+          exit 0
+        fi

Relevance

●●● Strong

Recent accepted workflow fixes show the team accepts CI logic that otherwise bypasses intended test
coverage.

PR-#521
PR-#200

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The action creates a new KinD cluster at lines 115-137 and installs OLM v0.31.0 at lines 171-180.
The added gate requires the OLM v1 ClusterExtension API and exits before the install and upgrade
commands at lines 381-393, so this action cannot execute the scenario it introduces.

.github/actions/test-charts/action.yml[115-137]
.github/actions/test-charts/action.yml[171-180]
.github/actions/test-charts/action.yml[365-393]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new upgrade test always skips because its freshly created CI cluster installs only legacy OLM and never provides the ClusterExtension API required by the test gate.

## Fix Focus Areas
- .github/actions/test-charts/action.yml[369-372]

## Recommended Fix
Provision a supported OLM v1 environment before this step, or move the scenario to a job backed by a cluster that exposes the ClusterExtension API. Make absence of that API fail the dedicated scenario rather than silently reporting success.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

8. Stuck resources block chart removal ⊘ Outdated 🐞 Bug ☼ Reliability ⭐ New

Description

delete_if_provisioned invokes kubectl delete with its default synchronous wait before executing
the separately bounded kubectl wait. When a Knative resource is held by a finalizer, the
pre-delete Job remains on the first command until Helm times out, so uninstall cannot proceed to
remove the operator resources.

Code

charts/orchestrator-infra/templates/serverless/knative-pre-delete.yaml[R64-65]

+                  kubectl delete "$kind" "$name" -n "$namespace" --ignore-not-found
+                  kubectl wait --for=delete "$kind/$name" -n "$namespace" --timeout=300s || true

Relevance

●●● Strong

Accepted precedent treats Helm hook hangs and bounded lifecycle cleanup as reliability issues
requiring fixes.

PR-#407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The cited cleanup function runs an unbounded synchronous delete before the command carrying the
intended 300-second timeout; the Job is declared as a pre-delete hook at
charts/orchestrator-infra/templates/serverless/knative-pre-delete.yaml[5-13], so blocking this
command blocks release removal.

charts/orchestrator-infra/templates/serverless/knative-pre-delete.yaml[57-68]
charts/orchestrator-infra/templates/serverless/knative-pre-delete.yaml[5-13]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The pre-delete hook runs a synchronous `kubectl delete` before its explicitly bounded wait, so a Knative resource held by a finalizer can block the hook until Helm times out.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/knative-pre-delete.yaml[64-65]

## Recommended Fix
Run `kubectl delete` with `--wait=false`, then use the existing bounded `kubectl wait --for=delete` as the only wait. Handle a wait timeout explicitly rather than allowing the first command to block without its own bound.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

9. Uninstall leaves Knative resources ⊘ Outdated 🐞 Bug ☼ Reliability

Description

The post-install Job creates the Knative instances with kubectl apply, outside Helm's release
manifest and without Helm ownership metadata. Uninstall deletes neither these instances nor their
retained namespaces, leaving infrastructure from the release in the cluster.

Code

charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[R117-120]

+              {{- if eq $unmanagedKnativeEventingExists "false" }}
+              if ! kubectl get knativeeventing knative-eventing -n knative-eventing >/dev/null 2>&1; then
+                echo "Creating KnativeEventing/knative-eventing..."
+                kubectl apply -f /manifests/knative-eventing.yaml

Relevance

●●● Strong

Hook-created, unowned instances persist after uninstall, creating a concrete cleanup gap.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Job applies plain manifests with no release ownership metadata, while its deletion policy
applies only to the hook objects; the chart separately marks both target namespaces as retained.

charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[75-78]
charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[117-128]
charts/orchestrator-infra/files/knative-eventing/knative-eventing-cr.yaml[1-7]
charts/orchestrator-infra/files/knative-serving/knative-serving-cr.yaml[1-10]
charts/orchestrator-infra/templates/serverless/knatives.yaml[4-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The v1 Job imperatively creates Knative custom resources that Helm does not track, so they remain after release removal. The namespaces are retained as well, making the leftover resources persist independently of the release.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/knative-v1-post-install.yaml[117-128]
- charts/orchestrator-infra/files/knative-eventing/knative-eventing-cr.yaml[1-7]
- charts/orchestrator-infra/files/knative-serving/knative-serving-cr.yaml[1-10]

## Recommended Fix
Add a properly weighted pre-delete cleanup hook that removes only the Knative instances created by this release before the operator is removed, while preserving externally managed instances detected during rendering.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View medium (4)

10. Valid catalog selectors are rejected ✓ Resolved 🐞 Bug ≡ Correctness

Description

The new schema sets additionalProperties: false for both selector and matchLabels, permitting
only the hard-coded metadata-name label and excluding matchExpressions. When users select a
catalog through another label or a standard expression, Helm rejects their values before the
templates can pass the selector to the ClusterExtension.

Code

charts/orchestrator-infra/values.schema.tmpl.json[R23-27]

+              "additionalProperties": false,
+              "properties": {
+                "matchLabels": {
+                  "type": "object",
+                  "additionalProperties": false,

Relevance

●●● Strong

Schema rejects valid Kubernetes selector forms and unnecessarily hard-codes one catalog label, a
clear configurability bug.

PR-#500

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The schema closes the selector object to everything except matchLabels, then closes that map to
every key except olm.operatorframework.io/metadata.name. Both ClusterExtension templates serialize
the value directly under spec.source.catalog.selector, so the schema—not the rendering
code—prevents alternative selector forms.

charts/orchestrator-infra/values.schema.tmpl.json[21-37]
charts/orchestrator-infra/values.schema.json[10-25]
charts/orchestrator-infra/templates/serverless/clusterextension.yaml[47-55]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[47-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The catalog selector schema accepts only one hard-coded `matchLabels` key and rejects standard selector forms such as arbitrary label keys and `matchExpressions`. The ClusterExtension templates otherwise pass the configured selector through unchanged.

## Fix Focus Areas
- charts/orchestrator-infra/values.schema.tmpl.json[21-37]
- charts/orchestrator-infra/values.schema.json[10-25]

## Recommended Fix
Model the value as a Kubernetes label selector: allow arbitrary string-valued keys under `matchLabels` and add the standard `matchExpressions` array structure with key, operator, and values fields. Regenerate `values.schema.json` from the corrected template and add schema-validation coverage for both selector forms.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

11. Same-named releases fail across namespaces ✓ Resolved 🐞 Bug ☼ Reliability

Description

unmanaged-clusterextension-exists passes only .Release.Name to is-managed-resource, so
ownership of the cluster-scoped ClusterExtension is determined solely from
meta.helm.sh/release-name rather than also checking the release namespace. When another namespace
contains an identically named Helm release, both ClusterExtension templates treat its existing
object as managed by the current release and render it with the current namespace annotation,
reaching Helm ownership validation with the other installation’s release-namespace annotation.

Code

charts/orchestrator-infra/templates/_helpers.tpl[R61-63]

+            {{- $isManagedResource := include "is-managed-resource" (list $existingExtension $releaseName) -}}
+            {{- if eq $isManagedResource "true" -}}
+                {{- "false" -}}

Relevance

●●● Strong

Cluster-scoped ownership must include release namespace to avoid false adoption of same-named
releases.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

ClusterExtensions are looked up without a namespace, while the new ownership helper receives and
compares only the release name even though rendered manifests record both
meta.helm.sh/release-name and meta.helm.sh/release-namespace. Both ClusterExtension templates
use this incomplete ownership result to decide whether to render the cluster-scoped resource, so an
object belonging to a same-named release in another namespace is mistaken for the current release’s
object even though it cannot be adopted because its namespace annotation differs.

charts/orchestrator-infra/templates/_helpers.tpl[52-66]
charts/orchestrator-infra/templates/_helpers.tpl[28-35]
charts/orchestrator-infra/templates/serverless/clusterextension.yaml[33-37]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[33-37]
charts/orchestrator-infra/templates/_helpers.tpl[28-36]
charts/orchestrator-infra/templates/serverless/clusterextension.yaml[4-5]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[4-5]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
ClusterExtension ownership is inferred from the Helm release name alone even though release names are namespace-scoped. An identically named release in another namespace can therefore be mistaken for the current owner, bypassing the collision guard and later failing Helm ownership validation.

## Fix Focus Areas
- charts/orchestrator-infra/templates/_helpers.tpl[28-36]
- charts/orchestrator-infra/templates/_helpers.tpl[52-66]
- charts/orchestrator-infra/templates/serverless/clusterextension.yaml[4-5]
- charts/orchestrator-infra/templates/serverless/clusterextension.yaml[33-37]
- charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[4-5]
- charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[33-37]

## Recommended Fix
Pass `.Release.Namespace` into the ClusterExtension lookup and ownership helper, then require both `meta.helm.sh/release-name` and `meta.helm.sh/release-namespace` to match before treating an existing ClusterExtension as managed by the current release. Treat a mismatch in either annotation as unmanaged or conflicting, preserving the intended skip behavior by suppressing creation or failing with a clear collision message.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

12. New installation guide is overwritten ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The OLM installation section was added directly to the generated README.md but not to
README.md.gotmpl, whose content proceeds directly from the values table to the Knative section.
The repository's mandatory helm-docs pre-commit hook therefore removes this guide, producing an
automatic deletion on same-repository branches or a failing check on forks.

Code

charts/orchestrator-infra/README.md[R107-109]

+### OLM v0 and OLM v1 operator installation
+
+By default, the chart uses `olmVersion: auto` to select the OLM API:

Relevance

●●● Strong

Generated README changes must be mirrored in the template; similar README maintenance was accepted
in PR #289.

PR-#289

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The generated README contains the new section, but its source template transitions directly from
chart.valuesSection to the Knative documentation. The configured pre-commit hook runs helm-docs
for README, chart, and values changes, and CI fails or auto-commits whenever regeneration modifies
tracked files.

charts/orchestrator-infra/README.md[107-123]
charts/orchestrator-infra/README.md.gotmpl[77-81]
.pre-commit-config.yaml[1-13]
.github/workflows/pre-commit.yaml[48-64]
.github/workflows/pre-commit.yaml[98-112]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new OLM installation guide exists only in the generated README, so the repository's documentation generation hook removes it.

## Fix Focus Areas
- charts/orchestrator-infra/README.md[107-123]
- charts/orchestrator-infra/README.md.gotmpl[77-81]

## Recommended Fix
Insert the OLM v0/v1 installation section into `README.md.gotmpl` immediately after the generated values section, then run the repository's `helm-docs` pre-commit hook to regenerate and commit `README.md`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

13. Configured catalogs are ignored ✓ Resolved 🔗 Cross-repo conflict ≡ Correctness

Description

Both new ClusterExtension templates render only package, channel, and, for Logic, version fields,
omitting source.catalog.selector and discarding the configured subscription.spec.source and
sourceNamespace values. When multiple catalogs provide an operator or an installation configures a
non-default catalog, including the v1 CI configuration selecting the olm namespace, OLM v1 cannot
honor that choice and may resolve from an unintended catalog.

Code

charts/orchestrator-infra/templates/serverless/clusterextension.yaml[R44-48]

+    catalog:
+      packageName: {{ $packageName }}
+      channels:
+        - {{ .Values.serverlessOperator.subscription.spec.channel }}
+      upgradeConstraintPolicy: CatalogProvided

Relevance

●●● Strong

Ignoring configured catalog fields breaks explicit catalog selection, including the new v1 CI
configuration.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The v1 manifests do not consume either configured catalog field even though the chart values retain
explicit catalog names and the v0 Subscription serializes the complete subscription spec. The
newly added v1 CI values also override sourceNamespace, demonstrating a real configuration that
the new resources discard, while the accepted OLM v1 decision records require selector pinning for
fresh installs and the related operator repository demonstrates the expected selector label and
placement.

charts/orchestrator-infra/templates/serverless/clusterextension.yaml[42-48]
charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[42-49]
charts/orchestrator-infra/values.yaml[16-19]
charts/orchestrator-infra/templates/serverless/subscription.yaml[8-9]
charts/orchestrator-infra/ci/upstream-olm-v1-values.yaml[1-14]
External repo: redhat-developer/rhdh-adr, decisions/004-olmv1-adoption.md [9-16]
External repo: redhat-developer/rhdh-operator, .rhdh/scripts/install-rhdh-catalog-source.sh [1197-1219]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The OLM v1 `ClusterExtension` templates ignore the chart's configured catalog source and namespace, preventing v1 installations from selecting the catalog used by the existing `Subscription` path and omitting the selector required by the accepted OLM v1 adoption flow.

## Fix Focus Areas
- charts/orchestrator-infra/templates/serverless/clusterextension.yaml[42-48]
- charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml[42-49]
- charts/orchestrator-infra/values.yaml[16-19]
- charts/orchestrator-infra/values.yaml[40-43]

## Recommended Fix
Translate the existing catalog configuration into supported OLM v1 catalog-selection fields in both `ClusterExtension` templates by adding `source.catalog.selector.matchLabels` and selecting `olm.operatorframework.io/metadata.name` from the configured catalog name, or introduce explicit v1 catalog values and consume them consistently in both templates. Document or replace `sourceNamespace` because OLM v1 `ClusterCatalog` resources are cluster-scoped, ensure the `upstream-olm-v1-values.yaml` override selects the intended upstream catalog rather than being silently ignored, and update tests to verify the rendered selector.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials

✅ Cross-repo context — repo relationships

  Explored: repo: redhat-developer/rhdh-operator (sha: 540c6d67)

  Explored: repo: redhat-developer/rhdh-adr (sha: 02b1e659)

Review mode: ⚖️ Balanced: Comparison failure: full PR diff.

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[rhdh-qodo-merge]

Important

The /generate_labels command by Qodo is sunsetting on the 1st of October 2026 and will no longer be available. We recommend switching to the latest Qodo review capabilities. Learn more

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 5b84aec

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit dbb6b4c

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 098f5e3

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 098f5e3

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 60e6711

[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