Repository navigation
TalosConfigTemplate is immutable but applied on every reconcile, so machine-config changes never propagate #3515
Description
What happened
TalosConfigTemplate has an immutable .spec (enforced by the vtalosconfigtemplate.cluster.x-k8s.io
webhook), but packages/apps/kubernetes/templates/talos/talos-reconcile-job.yaml applies it with
kubectl apply on every reconcile. As a result, once the template exists, no change to the rendered
Talos machine config can ever reach it. The apply is rejected server-side:
admission webhook "vtalosconfigtemplate.cluster.x-k8s.io" denied the request:
TalosConfigTemplate.Spec is immutable
This is silent: the Job does not surface it as a distinct error, and the kubernetes-* HelmRelease stays Ready.
Why it matters
Anything rendered into the machine config is frozen at first creation. Concretely, we hit this with
machine.network.searchDomains: our management cluster domain was misconfigured, we corrected
networking.clusterDomain, the chart then rendered the correct searchDomains, and the template kept the
stale value forever. The same applies to certSANs, machine.registries, nameservers, and any future
machine-config field.
The workaround is to delete + create the TalosConfigTemplate by hand for every tenant cluster after every
platform upgrade, which does not scale and is easy to forget.
Reproduce
- Create a tenant
Kubernetescluster and let the workers roll (v1.6.0, Talos workers). - Change any platform value that feeds the machine config, e.g.
networking.clusterDomain. - Let the
kubernetes-*HelmRelease upgrade andtalos-reconcilerun. kubectl -n <tenant-ns> get talosconfigtemplate <cluster>-<group> -o yamlstill shows the old value.
Suggested fix
Name the TalosConfigTemplate with a hash of its rendered content, the way
KubevirtMachineTemplate already is in the same chart, and point MachineDeployment.spec.template.spec.bootstrap.configRef
at the hashed name. A content change then creates a new template instead of attempting a rejected mutation,
and CAPI rolls the machines onto it, which is the desired behaviour anyway.
Alternatively, have talos-reconcile detect a content drift and perform the delete/create itself, but the hashed
name is the idiomatic CAPI pattern and avoids a destructive step.
Environment
Cozystack v1.6.0 (packages digest sha256:bf682087…), Talos v1.13.6 workers, Kubernetes v1.34.3 management.
Activity
dosubot commentedon Aug 3, 2026
Good catch — this is a real gap. The code confirms the asymmetry you described:
KubevirtMachineTemplatealready uses content-hashed naming incluster.yaml— it computes asha256sum | trunc 6of the rendered spec and appends it to the resource name (<release>-<group>-<hash>), so any spec change creates a new object and CAPI rolls the machines [1].TalosConfigTemplate, by contrast, uses a stable name${RELEASE}-${GROUP_NAME}with no hash [2]. The Job's own comment explains this was intentional — "an unchanged render re-applies a byte-identical TCT — a CAPI no-op that never rolls existing workers" [3] — but it doesn't account for the case where the rendered content actually does change, which hits the immutable-spec webhook exactly as you describe.The
MachineDeploymentalready references one hashed template (infrastructureRef→KubevirtMachineTemplate) and one unhashed template (bootstrap.configRef→TalosConfigTemplate) [4], so adopting the same hashed-name pattern forTalosConfigTemplatewould be consistent and straightforward:TalosConfigTemplatespec (samesha256sum | trunc 6approach).<release>-<group>-<hash>.MachineDeployment.spec.template.spec.bootstrap.configRef.nameto include the hash.TalosConfigTemplateobjects until noMachineSetreferences them (the chart already does this for oldKubevirtMachineTemplateobjects) [5].I didn't find an existing issue or PR tracking this, so this appears to be the first report.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
fix(kubernetes): name TalosConfigTemplate by content hash
fix(kubernetes): name TalosConfigTemplate by content hash
fix(kubernetes): name TalosConfigTemplate by content hash
fix(kubernetes): name TalosConfigTemplate by content hash
feat(kubernetes): per-pool kernel modules for Talos worker nodes (#3571)
fix(kubernetes): name TalosConfigTemplate by content hash
fix(kubernetes): name TalosConfigTemplate by content hash (cozystack#…