Summary
analyze_cert_manager counts pods from a hardcoded cert-manager namespace (backend/services/scanner/fetch.py:833) and gates detection on if has_crds and running_pods: (prereqs.py). When cert-manager is installed into a non-default namespace, the pod fetch reads 0 pods, which downgrades the reported status from DETECTED to PARTIAL, emits a wrong actionable recommendation to the operator (recommendations.py:72-78 — "cert-manager partially installed — CRDs found but some components may be missing. Running pods: 0."), raises a warning (adaptive_module_selector.py:470), and returns version = None.
Why this is HIGHER severity than #202
This is the same class as #202 (hardcoded pod-fetch namespace), but with a worse consequence. #202 was only a wrong number — the Multus DaemonSet was still discovered cluster-wide, so status stayed DETECTED. cert-manager has no such rescue: an empty pod list flips the status and drives a wrong recommendation.
Reachability
Reachable on the very platform that motivated #202:
- IBM ROKS installs the cert-manager add-on into
ibm-cert-manager
- older Red Hat operands sit in
openshift-cert-manager
- any Helm install can
--namespace it anywhere
Verified against a cert-manager healthy in a non-cert-manager namespace:
status = partial pods = {'controller': 0, 'webhook': 0, 'cainjector': 0, 'total_running': 0} version = None
Suggested fix
The mechanism is already in hand: helm_releases carries the release namespace, and the repo already has the right pattern in backend/services/bnk_pod_discovery.py:272 (_sweep_all_namespaces / list_pod_for_all_namespaces). One such sweep, partitioned by namespace/name, would collapse the three hardcoded-namespace pod fetches (fetch.py:833 cert-manager, :834 kube-system, :895 kamaji-system) into one and close the class permanently.
Context
Filed as a follow-up to PR #203 (issue #202, Multus openshift-multus). Raised by @bonnyr-f5 in round-1 review as Major M-1: the multus fix is 1-of-3 of this class; this cert-manager sibling is the highest-severity instance and was explicitly kept out of #203's scope.
https://claude.ai/code/session_01UCsZXDxBsWV2s4kT47DwDW
Summary
analyze_cert_managercounts pods from a hardcodedcert-managernamespace (backend/services/scanner/fetch.py:833) and gates detection onif has_crds and running_pods:(prereqs.py). When cert-manager is installed into a non-default namespace, the pod fetch reads 0 pods, which downgrades the reported status from DETECTED to PARTIAL, emits a wrong actionable recommendation to the operator (recommendations.py:72-78— "cert-manager partially installed — CRDs found but some components may be missing. Running pods: 0."), raises a warning (adaptive_module_selector.py:470), and returnsversion = None.Why this is HIGHER severity than #202
This is the same class as #202 (hardcoded pod-fetch namespace), but with a worse consequence. #202 was only a wrong number — the Multus DaemonSet was still discovered cluster-wide, so status stayed DETECTED. cert-manager has no such rescue: an empty pod list flips the status and drives a wrong recommendation.
Reachability
Reachable on the very platform that motivated #202:
ibm-cert-manageropenshift-cert-manager--namespaceit anywhereVerified against a cert-manager healthy in a non-
cert-managernamespace:Suggested fix
The mechanism is already in hand:
helm_releasescarries the release namespace, and the repo already has the right pattern inbackend/services/bnk_pod_discovery.py:272(_sweep_all_namespaces/list_pod_for_all_namespaces). One such sweep, partitioned by namespace/name, would collapse the three hardcoded-namespace pod fetches (fetch.py:833cert-manager,:834kube-system,:895kamaji-system) into one and close the class permanently.Context
Filed as a follow-up to PR #203 (issue #202, Multus
openshift-multus). Raised by @bonnyr-f5 in round-1 review as Major M-1: the multus fix is 1-of-3 of this class; this cert-manager sibling is the highest-severity instance and was explicitly kept out of #203's scope.https://claude.ai/code/session_01UCsZXDxBsWV2s4kT47DwDW