kubernetes: a cluster in tenant-root without etcd fails silently because cozystack-values hardcodes _namespace.etcd #4783

A tenant Kubernetes cluster created in tenant-root while the root Tenant has etcd disabled never comes up, and nothing tells the user why: its HelmRelease is Ready.

The root tenant's namespace values are hardcoded. packages/system/cozystack-basics/templates/cozystack-values-secret.yaml writes _namespace.etcd: tenant-root no matter what the root Tenant says. Every other tenant gets the value from packages/apps/tenant/templates/namespace.yaml, which sets it only when etcd is enabled on that tenant or an ancestor.

The kubernetes chart already guards against a tenant without etcd. When _namespace.etcd is empty, it renders only an awaiting-etcd ConfigMap that tells the user to set spec.etcd: true (b38ae60). In tenant-root the value is never empty, so the guard never fires.

What happens instead:

• the chart renders a KamajiControlPlane with dataStoreName: tenant-root;
• Kamaji's webhook rejects the TenantControlPlane with tenant-root DataStore does not exist, which only shows up in the KamajiControlPlane conditions;
• hr/kubernetes-<name> reports Helm install succeeded, and the addon releases wait on could not get KubeConfig secret ... admin-kubeconfig forever.

I hit this on v1.7.0-alpha.3 (isp-full-generic on k3s). After a fresh install I patched the root Tenant with host and ingress only, then created a Kubernetes application in tenant-root. Setting spec.etcd: true on the root Tenant was enough for the same cluster to come up. The code on main is the same.

I'd make the tenant-root values follow the root Tenant's spec.etcd, so the existing guard covers tenant-root too. The same Secret hardcodes monitoring and seaweedfs as well. I did not check whether their consumers have the same problem.

Installers that never enable etcd on the root Tenant make this easy to hit: cozystack/ansible-cozystack#84 and cozystack/ccp#27.