v0.8.50: Manager crash-loops because the Namespace CRD is not shipped with the Helm chart

[fatalerror12]

Summary

v0.8.50 added a new namespaces.redhatcop.redhat.io custom resource which the packaged Helm chart for never installs, while the compiled manager binary still registers a controller and webhooks that expect it to exist. The manager fails to start its cache for that kind, times out, and exits — causing the operator pod to crash-loop indefinitely.

Error message:

2026-07-15T13:44:32Z	ERROR	controller-runtime.source.EventHandler	if kind is a CRD, it should be installed before calling Start	{"kind": "Namespace.redhatcop.redhat.io", "error": "no matches for kind \"Namespace\" in version \"redhatcop.redhat.io/v1alpha1\""}
sigs.k8s.io/controller-runtime/pkg/internal/source.(*Kind).Start.func1.1
	/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.17.3/pkg/internal/source/kind.go:63
k8s.io/apimachinery/pkg/util/wait.loopConditionUntilContext.func2
	/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.29.2/pkg/util/wait/loop.go:87
k8s.io/apimachinery/pkg/util/wait.loopConditionUntilContext
	/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.29.2/pkg/util/wait/loop.go:88
k8s.io/apimachinery/pkg/util/wait.PollUntilContextCancel
	/home/runner/go/pkg/mod/k8s.io/apimachinery@v0.29.2/pkg/util/wait/poll.go:33
sigs.k8s.io/controller-runtime/pkg/internal/source.(*Kind).Start.func1
	/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.17.3/pkg/internal/source/kind.go:56
....
2026-07-15T13:44:32Z	ERROR	setup	problem running manager	{"error": "failed to wait for namespace caches to sync: timed out waiting for cache to be synced for Kind *v1alpha1.Namespace"}
main.main
	/home/runner/work/vault-config-operator/vault-config-operator/main.go:579
runtime.main
	/opt/hostedtoolcache/go/1.22.12/x64/src/runtime/proc.go:271

Version 0.8.49 is unaffected, since it predates the Namespace feature entirely.

Impact

Because the crash-looping pod also serves the admission webhooks for every other redhatcop.redhat.io resource (SecretEngineMount, PKISecretEngineConfig, Policy, etc.), any resource applied while the manager is mid-crash fails with connection refused against <release>-webhook-service. In practice this makes any install of v0.8.50 unreliable, not just anything that uses the new Namespace resource.

Steps to Reproduce

1. Install redhat-cop/vault-config-operator via Helm at chart version v0.8.50.
2. Observe the operator pod's restart count increase and cycle through CrashLoopBackOff.
3. kubectl get crd namespaces.redhatcop.redhat.io → NotFound, while the chart's other ~46 redhatcop.redhat.io CRDs are present.
4. kubectl logs <pod> --previous shows the cache-sync timeout above.

Root Cause

config/crd/kustomization.yaml's resources: list appears to be missing bases/redhatcop.redhat.io_namespaces.yaml, which otherwise exists in config/crd/bases/. That kustomization feeds the CRDs bundled into the Helm chart, so if that's the gap, the chart wouldn't ship the CRD the manager expects.

Suggested Solution

Add the missing line to config/crd/kustomization.yaml:

resources:
  ...
  - bases/redhatcop.redhat.io_namespaces.yaml

References

• Commit that introduced the gap: 3ad81db
• File missing the entry: https://github.com/redhat-cop/vault-config-operator/blob/main/config/crd/kustomization.yaml
• CRD file that exists but isn't referenced: https://github.com/redhat-cop/vault-config-operator/blob/main/config/crd/bases/redhatcop.redhat.io_namespaces.yaml