[Fortune-Ndlovu]

Summary

Adds an OLM v1 install path for orchestrator plugin-infra only (OpenShift Serverless + Serverless Logic). ArgoCD and Pipelines remain on the existing v0 Subscription manifests.

• Add serverless-v1.yaml and serverless-logic-v1.yaml with installer ServiceAccount, ClusterRoleBinding (cluster-admin), and ClusterExtension resources (catalog selector: openshift-redhat-operators)
• Update plugin-infra.sh to auto-detect OLM version or force via --olm-version v0|v1|auto
• Keep existing v0 manifests (serverless.yaml, serverless-logic.yaml) unchanged; both paths still apply knative.yaml after operator CRDs are available
• v1 resources are labeled rhdh.redhat.com/managed-by: plugin-infra; the script skips Helm-managed resources on apply/delete
• Delete removes v1 ClusterExtensions first (with wait), then Knative CRs, then v0 Subscriptions if present
• Makefile forwards OLM_VERSION to make plugin-infra / make plugin-infra-undeploy

Fixes: https://redhat.atlassian.net/browse/RHIDP-14659

Test plan

Prerequisites

• OpenShift cluster with oc/kubectl access and cluster-admin
• For v0 testing: any cluster with Red Hat Operators catalog (e.g. ROSA 4.22)
• For v1 testing: OCP 4.18+ cluster with OLM v1 enabled (ClusterExtension + ClusterCatalog CRDs and platform openshift-redhat-operators ClusterCatalog)

test from a local clone (recommended for this PR)

git clone https://github.com/Fortune-Ndlovu/rhdh-operator.git
cd rhdh-operator
git checkout RHIDP-14791-operator-add-olm-v-1-cluster-extension-manifests-for-plugin-infra-operators

1. OLM v0 path (works on ROSA / clusters without OLM v1)

cd config/profile/rhdh/plugin-infra

# Install
bash plugin-infra.sh --olm-version v0

# Verify operators
oc get subscription -n openshift-serverless serverless-operator
oc get subscription -n openshift-serverless-logic logic-operator
oc get csv -A | egrep 'serverless-operator|logic-operator'
oc get knativeserving -n knative-serving
oc get knativeeventing -n knative-eventing

# Uninstall
bash plugin-infra.sh delete --olm-version v0

Expected: script prints Using OLM v0; Subscriptions and Knative CRs are created/removed; no ClusterExtension resources.

2. Auto-detect on a non-OLM-v1 cluster

bash plugin-infra.sh

Expected: script prints Auto-detected OLM v0 (OLM v1 CRDs not found) and behaves like the v0 test above.

3. OLM v1 path (requires OLM v1 cluster)

# Confirm prerequisites
oc get crd clusterextensions.olm.operatorframework.io clustercatalogs.olm.operatorframework.io
oc get clustercatalog -l olm.operatorframework.io/metadata.name=openshift-redhat-operators

# Install
bash plugin-infra.sh --olm-version v1

# Verify operators
oc get clusterextension serverless-operator logic-operator
oc wait clusterextension/serverless-operator --for=condition=Installed --timeout=300s
oc wait clusterextension/logic-operator --for=condition=Installed --timeout=300s
oc get csv -A | egrep 'serverless-operator|logic-operator'
oc get knativeserving -n knative-serving
oc get knativeeventing -n knative-eventing

# Uninstall
bash plugin-infra.sh delete

Expected: ClusterExtensions reach Installed; Knative Serving/Eventing become Ready; delete removes ClusterExtensions before installer RBAC/namespaces.

4. Makefile targets

# From repo root
make plugin-infra PROFILE=rhdh OLM_VERSION=v0
make plugin-infra-undeploy PROFILE=rhdh OLM_VERSION=v0

[rhdh-qodo-merge]

PR Summary by Qodo

Add OLM v1 support to orchestrator plugin infrastructure

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Adds OLM v1 ClusterExtensions and installer RBAC for Serverless operators.
• Auto-detects OLM APIs while preserving forced v0 and v1 installation paths.
• Waits for v1 operator installation before creating dependent Knative resources.

Diagram

graph TD
  A["plugin-infra.sh"] --> B{"OLM v1 CRDs?"}
  B -->|Yes| C["v1 manifests"] --> D["ClusterExtensions"] --> E["Installed wait"] --> F["Knative resources"]
  B -->|No| G["v0 subscriptions"] --> F

Loading

High-Level Assessment

The dual-manifest approach is appropriate because it preserves the established standalone script and unchanged OLM v0 resources while cleanly adding OLM v1 support. Generating manifests through Helm or another templating layer could reduce duplication, but would add a runtime dependency and complicate direct local or remote manifest application.

Files changed (3) +171 / -5

Enhancement (1) +78 / -5

plugin-infra.shSelect and coordinate OLM v0 or v1 installations +78/-5

Select and coordinate OLM v0 or v1 installations

• Adds '--olm-version v0|v1|auto', validates explicit selections, and detects ClusterExtension and ClusterCatalog CRDs for automatic selection. It chooses version-specific manifests and waits for OLM v1 ClusterExtensions before applying dependent Knative resources.

config/profile/rhdh/plugin-infra/plugin-infra.sh

Other (2) +93 / -0

serverless-logic-v1.yamlDefine the Serverless Logic OLM v1 installation +47/-0

Define the Serverless Logic OLM v1 installation

• Creates the operator namespace, a cluster-admin installer ServiceAccount binding, and a ClusterExtension sourced from the stable Red Hat catalog channel. The Logic operator is pinned to version 1.38.0 with catalog-provided upgrade constraints.

config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml

serverless-v1.yamlDefine the OpenShift Serverless OLM v1 installation +46/-0

Define the OpenShift Serverless OLM v1 installation

• Creates the Serverless namespace, a cluster-admin installer ServiceAccount binding, and a ClusterExtension selecting the stable Serverless operator package from the Red Hat catalog.

config/profile/rhdh/plugin-infra/serverless-v1.yaml

[rhdh-qodo-merge]

Code Review by Qodo

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

1. Missing catalogs still select version 1 ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New

Description

redhat_operators_catalog_exists treats a successful label-filtered kubectl get as proof that at
least one matching catalog exists, although an empty list also exits successfully. When the v1 CRDs
exist without the Red Hat catalog, auto and forced detection select v1 and apply extensions whose
required package source is absent.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[139]

+  if resource_exists clustercatalog -l "${REDHAT_OPERATORS_CATALOG_LABEL}"; then

Relevance

●●● Strong

Catalog detection can falsely succeed on empty results, directly undermining the PR's
version-selection intent.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The helper returns immediately from the label-filtered query, and both resolution modes rely on that
result before choosing v1. Both new extensions then require a catalog with exactly this label.

config/profile/rhdh/plugin-infra/plugin-infra.sh[138-143]
config/profile/rhdh/plugin-infra/plugin-infra.sh[162-183]
config/profile/rhdh/plugin-infra/serverless-v1.yaml[45-54]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[45-55]

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 existence check succeeds when a label selector returns an empty resource list, causing OLM v1 to be selected without the catalog required by the new ClusterExtensions.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[138-143]

## Recommended Fix
Query the selected ClusterCatalogs using an output format such as `-o name`, verify that the result is nonempty, and retain the exact-name fallback while continuing to propagate genuine kubectl errors.

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

---

2. Cleanup can delete shared namespaces ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New

Description

delete_v0_manifest_if_present checks only the Subscription and, when it is absent, passes the
entire legacy manifest to kubectl delete. Each legacy manifest also contains an unlabeled
Namespace and OperatorGroup, so cleanup on a cluster without that Subscription can remove a
pre-existing namespace and everything it contains without applying either ownership guard to it.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[225]

+  apply_manifest "${file}"

Relevance

●●● Strong

Cleanup bypasses ownership checks for manifest resources, creating a concrete shared-namespace
deletion risk.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The deletion helper supplies only the Subscription to should_skip_resource_mutation, then deletes
all objects in the selected file. Both files begin with a Namespace and OperatorGroup that carry no
plugin-infra ownership label.

config/profile/rhdh/plugin-infra/plugin-infra.sh[216-226]
config/profile/rhdh/plugin-infra/plugin-infra.sh[306-309]
config/profile/rhdh/plugin-infra/serverless.yaml[1-17]
config/profile/rhdh/plugin-infra/serverless-logic.yaml[1-17]

Agent prompt

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

## Issue description
Legacy cleanup deletes complete multi-resource manifests after checking ownership of only the Subscription, allowing an absent Subscription to expose unrelated namespaces and operator groups to deletion.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[216-226]
- config/profile/rhdh/plugin-infra/serverless.yaml[1-17]
- config/profile/rhdh/plugin-infra/serverless-logic.yaml[1-17]

## Recommended Fix
Delete each legacy resource independently and apply ownership checks to each one, especially the Namespace. Add plugin-infra ownership labels during legacy installation, and preserve any existing unlabeled or externally managed namespace rather than deleting the whole manifest.

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

---

3. Uninstall can strand operator resources ✓ Resolved 🐞 Bug ☼ Reliability

Description

The delete path passes each complete v1 manifest to kubectl delete, where the Namespace, installer
ServiceAccount, and binding precede the ClusterExtension that depends on those credentials. During
v1 teardown, the installer identity can therefore disappear before extension removal completes,
leaving the extension or its managed cluster resources behind.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R138-140]

+  apply_manifest "${serverless_logic_manifest}"
  apply_manifest "knative.yaml"
-  apply_manifest "serverless.yaml"
+  apply_manifest "${serverless_manifest}"

Relevance

●● Moderate

Teardown ordering risk is credible, but no repository precedent addresses dependent operator
deletion sequencing.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both new manifests define and delete the namespace and ServiceAccount before the cluster-scoped
extension, while the extension explicitly names that ServiceAccount. The script deletes each whole
manifest without an extension-removal wait.

config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-36]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-36]

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 delete path removes installer namespaces, ServiceAccounts, and role bindings before ensuring that their ClusterExtensions have completed uninstalling.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-36]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-36]

## Recommended Fix
For v1 deletion, explicitly delete each ClusterExtension first and wait until it no longer exists before deleting Knative resources and the installer ServiceAccount, ClusterRoleBinding, and Namespace. Do not rely on resource order inside a multi-document `kubectl delete -f` operation to preserve the installer credentials through uninstall.

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

---

4. Missing option values fail opaquely ✓ Resolved 📘 Rule violation ≡ Correctness ⭐ New

Description

--olm-version assigns $2 directly instead of validating it with ${2:?...} before use. When the
option is the final argument, strict unset-variable handling aborts during parsing with a generic
$2 error before the script can validate or explain the missing required value.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R25-26]

+    --olm-version)
+      olm_version="$2"

Relevance

●●● Strong

Trivial Bash argument-validation bug; repository history accepts robustness fixes in this script.

PR-#1325

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 14 requires mandatory flag values to be checked before first use with failing
parameter expansion. The new option parser reads $2 directly, so an omitted value is not validated
with the required construct.

Rule 14: Validate required environment variables in bash using failing parameter expansion
config/profile/rhdh/plugin-infra/plugin-infra.sh[25-28]

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 required value following `--olm-version` is read without failing parameter expansion, producing an opaque unset positional-parameter error when omitted.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[25-28]

## Recommended Fix
Validate the second positional parameter before assigning it, such as `olm_version="${2:?--olm-version requires v0, v1, or auto}"`, and only then shift both arguments.

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

---

5. Legacy installs cannot be removed ✓ Resolved 📘 Rule violation ≡ Correctness ⭐ New

Description

delete unconditionally invokes both family-specific cleanup paths, while resource_exists treats
unavailable ClusterExtension or Subscription APIs as fatal errors rather than absent resources. This
occurs on OLM v0 clusters without the ClusterExtension CRD and can also occur on pure v1 clusters
without the Subscription API, stopping teardown before Knative, legacy operators, or other
plugin-managed resources are cleaned up.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[349]

+  delete_orchestrator_v1_operators

Relevance

●●● Strong

Unconditional cross-version cleanup conflicts with optional API availability and can abort teardown
prematurely.

PR-#1325

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The cited code shows that resource_exists recognizes only NotFound responses as absence and exits
on other kubectl failures, while the delete sequence unconditionally invokes the v1 cleanup first
and later probes legacy Subscriptions. Because the script already detects that the ClusterExtension
CRD may be absent, these unconditional cross-family probes demonstrate that an unavailable optional
API can terminate teardown instead of merely skipping cleanup for that resource family.

Rule 11: Guard reconciliation logic on optional CRD existence
config/profile/rhdh/plugin-infra/plugin-infra.sh[130-136]
config/profile/rhdh/plugin-infra/plugin-infra.sh[271-278]
config/profile/rhdh/plugin-infra/plugin-infra.sh[349-351]
config/profile/rhdh/plugin-infra/plugin-infra.sh[58-69]
config/profile/rhdh/plugin-infra/plugin-infra.sh[265-278]
config/profile/rhdh/plugin-infra/plugin-infra.sh[306-309]
config/profile/rhdh/plugin-infra/plugin-infra.sh[348-351]

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 delete path probes both OLM resource families unconditionally even when detection established that one family’s CRDs are absent. Because the generic existence helper treats an unavailable resource API as fatal, teardown can abort before Knative, legacy operators, or other plugin-managed resources are removed.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[58-69]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[265-291]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[293-309]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[348-351]

## Recommended Fix
Before invoking each family-specific cleanup routine or querying its resources, check whether that family’s CRDs exist. Use `detect_olm_v1_crd` to skip only ClusterExtension-specific operations when the ClusterExtension CRD is absent, and similarly skip Subscription-specific operations when that API is unavailable; continue safely cleaning plugin-managed installer accounts, bindings, namespaces, Knative resources, and applicable v0 manifests. Preserve fatal handling for authorization, connectivity, and other unexpected errors.

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

---

6. Version 1 operator installs can time out ✓ Resolved 📘 Rule violation ✧ Quality

Description

The catalog.selector in both new ClusterExtension manifests requires a ClusterCatalog labeled
openshift-redhat-operators, but the installation bundle neither creates nor documents that
catalog. When an OLM v1 cluster has the required CRDs but lacks a matching catalog object,
plugin-infra.sh applies the extension and reaches kubectl wait without the package source needed
to satisfy its Installed condition.

Code

config/profile/rhdh/plugin-infra/serverless-v1.yaml[R43-46]

+      selector:
+        matchLabels:
+          olm.operatorframework.io/metadata.name: openshift-redhat-operators
+      upgradeConstraintPolicy: CatalogProvided

Relevance

●●● Strong

Accepted precedent specifically fixes ClusterExtension selectors that fail to match the intended
ClusterCatalog.

PR-#3163

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 1 requires referenced custom resources to be included in the example bundle or
clearly identified as separately provided. Both new manifests select the same external catalog,
while the script verifies only that the ClusterCatalog kind exists and then waits for installation
without verifying a matching catalog object.

Rule 1: Include all dependent Kubernetes resources in example manifests
config/profile/rhdh/plugin-infra/serverless-v1.yaml[25-46]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[25-46]
config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
config/profile/rhdh/plugin-infra/plugin-infra.sh[101-126]

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 ClusterExtension manifests select a ClusterCatalog labeled `openshift-redhat-operators`, but the installation bundle does not provide that object or identify it as a prerequisite. Detecting the ClusterCatalog CRD alone does not establish that a matching catalog instance exists.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[43-46]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[44-46]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]

## Recommended Fix
Include a matching ClusterCatalog manifest in the installation bundle, or clearly document the externally provided catalog and make OLM v1 detection verify that an available ClusterCatalog has the required label before applying either ClusterExtension.

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

---

View medium (3)

7. Access errors select old manifests ✓ Resolved 🐞 Bug ☼ Reliability

Description

The detection helpers discard every kubectl get crd error, and resolve_olm_version interprets
any nonzero result as an absent v1 CRD. When CRD reads fail because of authorization, connectivity,
or context errors, auto mode proceeds with legacy Subscription manifests rather than stopping at the
underlying cluster-access failure.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R77-82]

+  if detect_olm_v1_crd && detect_olm_v1_clustercatalog_crd; then
+    resolved_olm_version="v1"
+    echo "Auto-detected OLM v1 (ClusterExtension and ClusterCatalog CRDs found)"
+  else
+    resolved_olm_version="v0"
+    echo "Auto-detected OLM v0 (OLM v1 CRDs not found)"

Relevance

●●● Strong

Accepted precedent favors stopping on kubectl failures instead of masking access errors.

PR-#1325

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both helpers redirect all output and expose only the command status, while the automatic branch maps
any failed status directly to v0. The selected generation then controls which materially different
manifest files are applied or deleted.

config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
config/profile/rhdh/plugin-infra/plugin-infra.sh[77-83]
config/profile/rhdh/plugin-infra/plugin-infra.sh[109-115]

Agent prompt

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

## Issue description
OLM auto-detection treats all Kubernetes command failures as missing v1 CRDs, silently selecting legacy manifests when detection itself was not reliable.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[63-82]

## Recommended Fix
Make each detector distinguish a successful NotFound result from authorization, connectivity, and configuration failures. Return false only when the CRD is conclusively absent, and print the original error and exit nonzero for every operational failure; apply the same distinction to forced v1 validation.

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

---

8. Undeploy leaves forced installs behind ✓ Resolved 🐞 Bug ≡ Correctness

Description

resolve_olm_version recomputes the manifest family for every invocation rather than determining
which resources the delete action previously installed. A forced legacy install followed by an
unqualified delete on a v1-capable cluster selects the v1 files instead, and the Makefile undeploy
target always uses that unqualified form.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[107]

+resolve_olm_version

Relevance

●● Moderate

Version-dependent cleanup is plausible, but no close precedent confirms persistence of
installation-time selection.

PR-#2036

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Forced and automatic resolution can choose different generations, but the delete branch removes only
the currently resolved manifests. The repository's undeploy target invokes plugin-infra.sh delete
without forwarding an installation-time version.

config/profile/rhdh/plugin-infra/plugin-infra.sh[56-83]
config/profile/rhdh/plugin-infra/plugin-infra.sh[107-115]
config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
Makefile[432-435]

Agent prompt

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

## Issue description
Delete mode resolves the OLM generation from current cluster capabilities, which can differ from the generation explicitly selected during installation and cause it to delete the wrong resources.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[107-115]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- Makefile[432-435]

## Recommended Fix
In auto delete mode, inspect for the known ClusterExtensions and legacy Subscriptions and delete whichever families are actually present, allowing both during migrations. Alternatively, persist and reuse the installation selection and provide a Makefile variable that forwards the same `--olm-version` value to both deployment and undeployment.

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

---

9. Script deletes chart-managed operators ✓ Resolved 🔗 Cross-repo conflict ☼ Reliability

Description

apply_manifest passes delete directly to kubectl for the selected v1 manifests without
verifying ownership of their resources. When the orchestrator-infra Helm chart already owns the
identically named ClusterExtensions, installer accounts, bindings, or namespaces, this path removes
the chart release's operator infrastructure as well.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R138-140]

+  apply_manifest "${serverless_logic_manifest}"
  apply_manifest "knative.yaml"
-  apply_manifest "serverless.yaml"
+  apply_manifest "${serverless_manifest}"

Relevance

●● Moderate

Ownership-aware deletion is a valid reliability concern, but historical evidence is insufficient for
confident team behavior.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR's delete branch submits complete v1 manifests containing the same cluster-scoped and
namespaced identities rendered by rhdh-chart. The chart explicitly uses Helm release annotations to
distinguish managed from unmanaged resources, but the script performs no corresponding ownership
check before deletion.

config/profile/rhdh/plugin-infra/plugin-infra.sh[86-98]
config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-46]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-47]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/serverless/clusterextension.yaml [15-48]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml [15-50]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/_helpers.tpl [28-37]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/_helpers.tpl [52-70]

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 delete path can remove resources owned by an orchestrator-infra Helm release because both installers use identical resource names and the script performs an unconditional `kubectl delete -f`.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[86-98]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-46]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-47]

## Recommended Fix
Label or annotate resources created by plugin-infra with an installer-specific ownership marker. Before applying or deleting an existing resource, verify that marker; refuse to mutate Helm-owned resources, and delete only individually verified plugin-infra resources rather than deleting each complete manifest unconditionally.

ⓘ 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

✅ Compliance rules (platform): 18 rules

✅ Cross-repo context — repo relationships

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

  Explored: repo: redhat-developer/rhdh-chart (sha: e6e1319d)

Review mode: ⚖️ Balanced: This push adds substantial shell orchestration with separate OLM detection, apply, delete, resource-ownership, and wait paths plus privileged ClusterExtension manifests, creating real behavioral and cluster-impact risk best handled in one complete review.

Tip of the day

💡 Did you know, you can route each action level your way: inline, summary, both, or drop

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 6b55bc0

Results up to commit 807334c ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Uninstall can strand operator resources ✓ Resolved 🐞 Bug ☼ Reliability

Description

The delete path passes each complete v1 manifest to kubectl delete, where the Namespace, installer
ServiceAccount, and binding precede the ClusterExtension that depends on those credentials. During
v1 teardown, the installer identity can therefore disappear before extension removal completes,
leaving the extension or its managed cluster resources behind.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R138-140]

+  apply_manifest "${serverless_logic_manifest}"
  apply_manifest "knative.yaml"
-  apply_manifest "serverless.yaml"
+  apply_manifest "${serverless_manifest}"

Relevance

●● Moderate

Teardown ordering risk is credible, but no repository precedent addresses dependent operator
deletion sequencing.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both new manifests define and delete the namespace and ServiceAccount before the cluster-scoped
extension, while the extension explicitly names that ServiceAccount. The script deletes each whole
manifest without an extension-removal wait.

config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-36]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-36]

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 delete path removes installer namespaces, ServiceAccounts, and role bindings before ensuring that their ClusterExtensions have completed uninstalling.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-36]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-36]

## Recommended Fix
For v1 deletion, explicitly delete each ClusterExtension first and wait until it no longer exists before deleting Knative resources and the installer ServiceAccount, ClusterRoleBinding, and Namespace. Do not rely on resource order inside a multi-document `kubectl delete -f` operation to preserve the installer credentials through uninstall.

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

---

2. Version 1 operator installs can time out ✓ Resolved 📘 Rule violation ✧ Quality

Description

The catalog.selector in both new ClusterExtension manifests requires a ClusterCatalog labeled
openshift-redhat-operators, but the installation bundle neither creates nor documents that
catalog. When an OLM v1 cluster has the required CRDs but lacks a matching catalog object,
plugin-infra.sh applies the extension and reaches kubectl wait without the package source needed
to satisfy its Installed condition.

Code

config/profile/rhdh/plugin-infra/serverless-v1.yaml[R43-46]

+      selector:
+        matchLabels:
+          olm.operatorframework.io/metadata.name: openshift-redhat-operators
+      upgradeConstraintPolicy: CatalogProvided

Relevance

●●● Strong

Accepted precedent specifically fixes ClusterExtension selectors that fail to match the intended
ClusterCatalog.

PR-#3163

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Compliance rule 1 requires referenced custom resources to be included in the example bundle or
clearly identified as separately provided. Both new manifests select the same external catalog,
while the script verifies only that the ClusterCatalog kind exists and then waits for installation
without verifying a matching catalog object.

Rule 1: Include all dependent Kubernetes resources in example manifests
config/profile/rhdh/plugin-infra/serverless-v1.yaml[25-46]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[25-46]
config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
config/profile/rhdh/plugin-infra/plugin-infra.sh[101-126]

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 ClusterExtension manifests select a ClusterCatalog labeled `openshift-redhat-operators`, but the installation bundle does not provide that object or identify it as a prerequisite. Detecting the ClusterCatalog CRD alone does not establish that a matching catalog instance exists.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[43-46]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[44-46]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]

## Recommended Fix
Include a matching ClusterCatalog manifest in the installation bundle, or clearly document the externally provided catalog and make OLM v1 detection verify that an available ClusterCatalog has the required label before applying either ClusterExtension.

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

---

3. Access errors select old manifests ✓ Resolved 🐞 Bug ☼ Reliability

Description

The detection helpers discard every kubectl get crd error, and resolve_olm_version interprets
any nonzero result as an absent v1 CRD. When CRD reads fail because of authorization, connectivity,
or context errors, auto mode proceeds with legacy Subscription manifests rather than stopping at the
underlying cluster-access failure.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R77-82]

+  if detect_olm_v1_crd && detect_olm_v1_clustercatalog_crd; then
+    resolved_olm_version="v1"
+    echo "Auto-detected OLM v1 (ClusterExtension and ClusterCatalog CRDs found)"
+  else
+    resolved_olm_version="v0"
+    echo "Auto-detected OLM v0 (OLM v1 CRDs not found)"

Relevance

●●● Strong

Accepted precedent favors stopping on kubectl failures instead of masking access errors.

PR-#1325

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Both helpers redirect all output and expose only the command status, while the automatic branch maps
any failed status directly to v0. The selected generation then controls which materially different
manifest files are applied or deleted.

config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
config/profile/rhdh/plugin-infra/plugin-infra.sh[77-83]
config/profile/rhdh/plugin-infra/plugin-infra.sh[109-115]

Agent prompt

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

## Issue description
OLM auto-detection treats all Kubernetes command failures as missing v1 CRDs, silently selecting legacy manifests when detection itself was not reliable.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[48-54]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[63-82]

## Recommended Fix
Make each detector distinguish a successful NotFound result from authorization, connectivity, and configuration failures. Return false only when the CRD is conclusively absent, and print the original error and exit nonzero for every operational failure; apply the same distinction to forced v1 validation.

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

---

4. Undeploy leaves forced installs behind ✓ Resolved 🐞 Bug ≡ Correctness

Description

resolve_olm_version recomputes the manifest family for every invocation rather than determining
which resources the delete action previously installed. A forced legacy install followed by an
unqualified delete on a v1-capable cluster selects the v1 files instead, and the Makefile undeploy
target always uses that unqualified form.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[107]

+resolve_olm_version

Relevance

●● Moderate

Version-dependent cleanup is plausible, but no close precedent confirms persistence of
installation-time selection.

PR-#2036

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Forced and automatic resolution can choose different generations, but the delete branch removes only
the currently resolved manifests. The repository's undeploy target invokes plugin-infra.sh delete
without forwarding an installation-time version.

config/profile/rhdh/plugin-infra/plugin-infra.sh[56-83]
config/profile/rhdh/plugin-infra/plugin-infra.sh[107-115]
config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
Makefile[432-435]

Agent prompt

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

## Issue description
Delete mode resolves the OLM generation from current cluster capabilities, which can differ from the generation explicitly selected during installation and cause it to delete the wrong resources.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[107-115]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- Makefile[432-435]

## Recommended Fix
In auto delete mode, inspect for the known ClusterExtensions and legacy Subscriptions and delete whichever families are actually present, allowing both during migrations. Alternatively, persist and reuse the installation selection and provide a Makefile variable that forwards the same `--olm-version` value to both deployment and undeployment.

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

---

View medium (1)

5. Script deletes chart-managed operators ✓ Resolved 🔗 Cross-repo conflict ☼ Reliability

Description

apply_manifest passes delete directly to kubectl for the selected v1 manifests without
verifying ownership of their resources. When the orchestrator-infra Helm chart already owns the
identically named ClusterExtensions, installer accounts, bindings, or namespaces, this path removes
the chart release's operator infrastructure as well.

Code

config/profile/rhdh/plugin-infra/plugin-infra.sh[R138-140]

+  apply_manifest "${serverless_logic_manifest}"
  apply_manifest "knative.yaml"
-  apply_manifest "serverless.yaml"
+  apply_manifest "${serverless_manifest}"

Relevance

●● Moderate

Ownership-aware deletion is a valid reliability concern, but historical evidence is insufficient for
confident team behavior.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR's delete branch submits complete v1 manifests containing the same cluster-scoped and
namespaced identities rendered by rhdh-chart. The chart explicitly uses Helm release annotations to
distinguish managed from unmanaged resources, but the script performs no corresponding ownership
check before deletion.

config/profile/rhdh/plugin-infra/plugin-infra.sh[86-98]
config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-46]
config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-47]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/serverless/clusterextension.yaml [15-48]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/serverless-logic/clusterextension.yaml [15-50]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/_helpers.tpl [28-37]
External repo: redhat-developer/rhdh-chart, charts/orchestrator-infra/templates/_helpers.tpl [52-70]

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 delete path can remove resources owned by an orchestrator-infra Helm release because both installers use identical resource names and the script performs an unconditional `kubectl delete -f`.

## Fix Focus Areas
- config/profile/rhdh/plugin-infra/plugin-infra.sh[86-98]
- config/profile/rhdh/plugin-infra/plugin-infra.sh[137-140]
- config/profile/rhdh/plugin-infra/serverless-v1.yaml[1-46]
- config/profile/rhdh/plugin-infra/serverless-logic-v1.yaml[1-47]

## Recommended Fix
Label or annotate resources created by plugin-infra with an installer-specific ownership marker. Before applying or deleting an existing resource, verify that marker; refuse to mutate Helm-owned resources, and delete only individually verified plugin-infra resources rather than deleting each complete manifest unconditionally.

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

---

[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

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Code review by qodo was updated up to the latest commit 86bee84

[github-actions]

✅ PR images built and pushed successfully!

Images are available for testing (expires in 7 days):

Image	Full tag	PR tag
Operator	quay.io/rhdh-community/operator:2.0.0-pr-3555-32d5d94	quay.io/rhdh-community/operator:2.0.0-pr-3555
Bundle	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555-32d5d94	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555
Catalog	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555-32d5d94	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555

[rm3l]

Looks good, but can you address the ShellCheck warnings reported?

[github-actions]

✅ PR images built and pushed successfully!

Images are available for testing (expires in 7 days):

Image	Full tag	PR tag
Operator	quay.io/rhdh-community/operator:2.0.0-pr-3555-12e551b	quay.io/rhdh-community/operator:2.0.0-pr-3555
Bundle	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555-12e551b	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555
Catalog	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555-12e551b	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555

[sonarqubecloud]

Quality Gate passed

Issues
4 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

[github-actions]

✅ PR images built and pushed successfully!

Images are available for testing (expires in 7 days):

Image	Full tag	PR tag
Operator	quay.io/rhdh-community/operator:2.0.0-pr-3555-6b55bc0	quay.io/rhdh-community/operator:2.0.0-pr-3555
Bundle	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555-6b55bc0	quay.io/rhdh-community/operator-bundle:2.0.0-pr-3555
Catalog	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555-6b55bc0	quay.io/rhdh-community/operator-catalog:2.0.0-pr-3555