0061. A TalosMachine re-reconciles when a render input's spec changes

Status: Accepted · Date: 2026-10-26 · Design section: Nodes Decided: TalosMachineReconciler watches TalosStorage, TalosConfigPatch and TalosCluster through one mapping, machinesOfCluster (every machine of the object's cluster), filtered to creates, deletes and spec changes (predicate.GenerationChangedPredicate); a Secret named by registries[].authSecretRef (controller namespace only) maps through an index on TalosCluster to the machines of the clusters that reference it, and a hash of the resolved credentials joins the desired-inputs hash (follow-up below)

Context

SetupWithManager watched only TalosMachine and TalosStorage, and cmd/main.go sets no SyncPeriod, so an edit to a TalosConfigPatch or to the render inputs of a TalosCluster (kubernetesVersion, registries, driftPolicy, ...) reached an already converged node after up to 10 hours. ADR 0060's requeue does not help: it only revisits machines whose last reconcile failed, and a converged machine returns an empty Result.

Decision

• One mapping, machinesOfCluster, serves all three watches: a TalosCluster maps by its own name, a TalosConfigPatch and a TalosStorage by spec.clusterRef. It replaces machinesForStorage; there is one function declaring a TalosMachineList for this, in the same countplanes_guard_test.go allow-list slot.
• Each watch uses predicate.GenerationChangedPredicate. It filters update events only, so create and delete still enqueue, and a status write (a TalosCluster going Transitioning, a TalosStorage condition) does not wake every machine of the cluster. These are CRDs with a status subresource, so generation moves exactly on spec writes.
• envtest runs the real manager and checks that a patch created, or a registry mirror added, after the machine converged is applied within 15s, under the 30s requeue of ADR 0060, so the watch is what delivers it.

Secrets are not watched (superseded: they are now)

Follow-up (a changed credential used to be a reboot-requiring path; since ADR 0009's registry addendum it is applied live, so the watch makes the machine apply it promptly): the machine controller watches Secrets in the controller namespace, mapped through a TalosCluster field index on authSecretRef.name; the Secret informer already existed (cache.go scopes it to that namespace), so no RBAC changes. desiredInputsHash includes registryAuthFingerprint (a hash of the resolved password/auth/identityToken, not the resourceVersion, so label edits do not count), and the TalosStorage status controller computes the same value. The text below is the original reasoning.

spec.registries[].authSecretRef (ADR 0027) is a render input too, but a Secret watch needs a decision this change should not make quietly: the controller's Secret RBAC is namespace-scoped to ichor-system, and a watch is a cached informer over every Secret there, plus a mapping from Secret to the clusters that reference it. The load and the privilege are real and the case is rare.

The operational consequence: after changing a registry password, nothing happens until some spec of a render input of that cluster changes (touching the TalosCluster spec, for instance) or the controller restarts or resyncs (up to 10 hours). If this proves too slow, a follow-up can watch Secrets with a label or an authSecretRef index.

ADR 0060's requeue stays failure-only: a change reaching a converged machine is the watch's job.