Follow-up to the review of #3523, raised there as out of scope for that PR.
Context
#3523 names the worker TalosConfigTemplate after a content hash of the machine config it renders, because the object is immutable — the vtalosconfigtemplate.cluster.x-k8s.io webhook rejects any mutation, so a fixed name means a changed machine config can never reach the cluster. With the hash in the name, each change creates a new object instead.
That PR deliberately prunes nothing. The outgoing MachineSet still references the previous template while it drains, so deleting on sight would break a rollout in progress, and the superseded objects are instead left to be garbage-collected with the KamajiControlPlane when the cluster is deleted.
The consequence is accumulation: a cluster whose machine config changes often carries one TalosConfigTemplate per past revision for its whole life.
What a fix would look like
The chart already solves the same problem for KubevirtMachineTemplate. packages/apps/kubernetes-nodes/templates/nodegroup.yaml:629 enumerates live MachineSets and re-emits only those hash-named templates a MachineSet still points at, scoped by the meta.helm.sh/release-name annotation so sibling pool releases in one namespace do not fight over each other's objects.
The same enumeration gives a safe prune condition for TalosConfigTemplate: a template no MachineSet references through spec.template.spec.bootstrap.configRef is not in use by a rollout and can be dropped. The asymmetry is only that the two kinds are reached through different fields of the MachineSet — infrastructureRef for one, bootstrap.configRef for the other.
Worth checking before implementing: whether the Machines of a draining MachineSet can outlive their MachineSet, in which case the enumeration needs to cover Machine as well, and whether a pool release that is suspended or mid-upgrade can render with an empty lookup and prune everything at once.
Not urgent
The accumulated objects are small and inert, and the KamajiControlPlane ownerReference means they do not outlive the cluster. This is housekeeping, not a defect.
Follow-up to the review of #3523, raised there as out of scope for that PR.
Context
#3523 names the worker
TalosConfigTemplateafter a content hash of the machine config it renders, because the object is immutable — thevtalosconfigtemplate.cluster.x-k8s.iowebhook rejects any mutation, so a fixed name means a changed machine config can never reach the cluster. With the hash in the name, each change creates a new object instead.That PR deliberately prunes nothing. The outgoing
MachineSetstill references the previous template while it drains, so deleting on sight would break a rollout in progress, and the superseded objects are instead left to be garbage-collected with theKamajiControlPlanewhen the cluster is deleted.The consequence is accumulation: a cluster whose machine config changes often carries one
TalosConfigTemplateper past revision for its whole life.What a fix would look like
The chart already solves the same problem for
KubevirtMachineTemplate.packages/apps/kubernetes-nodes/templates/nodegroup.yaml:629enumerates liveMachineSets and re-emits only those hash-named templates aMachineSetstill points at, scoped by themeta.helm.sh/release-nameannotation so sibling pool releases in one namespace do not fight over each other's objects.The same enumeration gives a safe prune condition for
TalosConfigTemplate: a template noMachineSetreferences throughspec.template.spec.bootstrap.configRefis not in use by a rollout and can be dropped. The asymmetry is only that the two kinds are reached through different fields of theMachineSet—infrastructureReffor one,bootstrap.configReffor the other.Worth checking before implementing: whether the
Machines of a drainingMachineSetcan outlive theirMachineSet, in which case the enumeration needs to coverMachineas well, and whether a pool release that is suspended or mid-upgrade can render with an empty lookup and prune everything at once.Not urgent
The accumulated objects are small and inert, and the
KamajiControlPlaneownerReference means they do not outlive the cluster. This is housekeeping, not a defect.