Cluster create form: cilium/coredns shown among toggleable addons without an enable toggle #3108

Summary

When creating a tenant Kubernetes cluster, the addon section lists cilium and coredns without an enable toggle, unlike the other addons (cert-manager, fluxcd, ingress-nginx, …) which show an on/off switch. Users read "no toggle" as "I can't enable cilium from the form" and resort to the YAML editor — where setting cilium.enabled: true does nothing.

This is not a functional bug (cilium always works) but a misleading UX: a mandatory, always-on component is presented in the same list as optional toggleable addons, just missing its switch.

Mechanism

The form treats a schema object as a toggleable addon only when it declares an enabled field:

• apps/console/src/components/CustomObjectFieldTemplate.tsx:51-54 — isAddon = hasEnabledField && hasOtherFields. With an enabled boolean the field renders as a checkbox that gates a config panel.

cilium and coredns are the CNI and DNS of the tenant cluster — mandatory, not disableable — so their values schema intentionally has no enabled field, only valuesOverride. The Helm template deploys cilium unconditionally (gated only by the cluster's own etcd namespace, not by any addons.cilium.enabled), and reads only addons.cilium.valuesOverride. So a user who adds cilium.enabled: true in the YAML editor gets a silently-ignored no-op (the key is accepted by the schema but consumed by nothing), while believing they just enabled the CNI.

Net effect: the form correctly omits a toggle for a component that can't be toggled, but the surrounding presentation makes that look like a gap.

Suggested fix

Present mandatory components (cilium, coredns) distinctly from optional addons — e.g. a separate "always-on / configure-only" grouping or an explicit "always enabled" label — so users don't look for a missing switch or paste a no-op into YAML.

Source

A user on v1.4.2 reported being unable to enable cilium from the form and falling back to cilium.enabled: true in YAML.