bug(chart): multi-doc renderer ignores user-supplied machine.network.interfaces

[lexfrei]

What

On the Talos v1.12 multi-doc rendering path (charts/generic/templates/_helpers.tpl:talos.config.network.multidoc), the chart fully reconstructs network configuration from live discovery resources (links, addresses, routes) and explicitly does NOT consult talm.discovered.existing_interfaces_configuration.

Source comment (charts/generic/templates/_helpers.tpl:87-90):

Multi-doc format always reconstructs network config from discovery resources.
existing_interfaces_configuration is not used here because v1.12 nodes store
network config in separate documents (LinkConfig, BondConfig, etc.), not in
the legacy machine.network.interfaces field.

The premise — "v1.12 nodes already store network config in separate documents" — does not hold for clusters that were upgraded from a pre-1.12 chart. Their running MachineConfig still carries machine.network.interfaces[] from the legacy schema, and the multi-doc renderer drops it on first re-render.

Symptom

A user upgrading from v0.23 to v0.24+ does not get an automatic migration of legacy machine.network.interfaces[] declarations into multi-doc form. The legacy declarations vanish from the rendered config.

This is invisible at template time: talm template produces a config that looks complete (HostnameConfig, ResolverConfig, one LinkConfig / VLANConfig / BondConfig for the gateway link) but is missing every secondary interface, every secondary VLAN, every static route, and every user-side override that lived under machine.network.interfaces.

Reproduction shape (any of these triggers it)

• Node with two NICs, one routed (gateway link) and one for storage.
• Node with multiple VLANs, only one of which carries the default route.
• values.yaml that injects extra interfaces, addresses, or routes via the legacy machine.network.interfaces[] schema.

Affected versions

Introduced in #116 (v0.24.0). Present in main as of writing.

Possible directions

1. Consult existing_interfaces_configuration in multi-doc mode and translate non-trivial entries into LinkConfig / VLANConfig / BondConfig / RouteConfig documents.
2. Read the user-supplied source values (the machine.network.interfaces[] block in values.yaml) and translate them at render time.
3. As an immediate guardrail: hard-fail or emit a noisy warning when multi-doc mode would drop a non-empty existing_interfaces_configuration. Smallest change; unblocks users until a real translator is built.

Option 3 is recommended as the first step.

[lexfrei]

Adding context from a reproduction @kvaps ran:

Root failure mode confirmed. When talosVersion: "v1.11" is set in Chart.yaml, talm renders the legacy machine.network.interfaces[*] schema. If the actual node is on Talos v1.12 it stores its network in multi-doc form (LinkConfig, HostnameConfig, ResolverConfig, Layer2VIPConfig). c.ApplyConfiguration is replace-within-a-document, but a legacy machine.network.interfaces[0].mtu and a multi-doc LinkConfig name: enp0s31f6 sit in parallel namespaces — the legacy update never reaches the typed document. First apply: mtu in the legacy section, multi-doc LinkConfig untouched. Subsequent applies dropping mtu from the legacy section: same — multi-doc LinkConfig retains whatever was there before. The "patch retains old values" symptom is real, but it is not talm patch semantics; it is the schema split.

Switching the chart to talosVersion: "v1.12" against the same v1.12 node surfaces the other half of the gap directly:

rpc error: InvalidArgument
* static hostname is already set in v1alpha1 config
* .machine.network.nameservers is already set in v1alpha1 config

Talos rejects legacy network fields in the v1alpha1 root document when the same fields already exist in their typed multi-doc counterparts.

MTU specifically. The multi-doc LinkConfig template at charts/talm/templates/_helpers.tpl:212-223 (and the cozystack / generic mirrors) emits only name / addresses / routes. There is no mtu field on LinkConfig or VLANConfig even when the user supplies one in values.yaml or in legacy machine.network.interfaces[].mtu. Two separate fixes are needed:

• Translate user-supplied legacy fields (mtu and the rest) into their typed multi-doc equivalents — this is the scope this issue tracks.
• Surface the field on the chart's own multi-doc emit so a fresh discovery-driven render carries it through — overlaps with bug(chart): multi-doc renderer emits network docs only for the gateway-bearing link #142.

Cross-references.

• The $patch: delete lookup-failed regression mentioned in passing is tracked as talm apply breaks $patch: delete on paths absent in freshly generated config (regression after #139) #144 and being addressed in fix(engine): treat $patch:delete on absent paths as no-op #146 (no-op semantics for delete-on-absent-path, matching k8s SMP).
• Broader "multi-doc renderer covers a single link only" gap is bug(chart): multi-doc renderer emits network docs only for the gateway-bearing link #142.
• VLAN sub-interface dropped on multi-doc path: bug(chart): VLAN sub-interface missing from talm template output on v1.12 multi-doc path #140 / talm template --talos-version v1.12 does not discover VLAN interfaces from running node #143.