Boot-interface management used to be scattered and implicit — there was no single notion of "this machine's boot interface," so following it through discovery, ownership, and re-ingestion meant inferring it differently in each place. We've since formalized it around one type, MachineBootInterface (a MAC paired with its vendor-native Redfish interface id), and now track it deliberately across the machine lifecycle: what exploration observed (explored_endpoints), what we predict before the first lease (predicted_machine_interfaces), the owned and authoritative row (machine_interfaces), and the pair we deliberately retain across a delete and re-ingest (retained_boot_interfaces). Four stages, one coherent model — a real step up from where this began.
This command makes that model directly visible. admin-cli machine boot-interfaces <machine-id> reads the MachineBootInterface at each lifecycle stage for one machine and prints them together — ASCII table (default), JSON, or YAML — so you can see and verify a machine's boot interface end to end in one place. And when something looks off, you can tell exactly which stage diverges.
What it delivers:
- A per-stage view for a given MachineId: the MAC and Redfish interface id from each store, plus the
primary_interface flag and recorded_at where they apply.
- The effective boot interface the system selects (
pick_boot_interface), and a flag when the stages disagree — so "is this machine's boot NIC what I expect, everywhere?" is one command.
- ASCII-table / JSON / YAML via the existing
--output formats.
Mechanically: a new read-only GetMachineBootInterfaces Forge RPC and handler that gathers the four stores (the reads already exist), a small non-consuming retained_boot_interfaces read so retained rows stay visible, and the machine boot-interfaces subcommand. Tests cover the three renderers and an end-to-end read that seeds all four stores for a machine.
The model is far more cohesive than it was; a single view across the stages also gives us a clean surface to keep simplifying against over time.
Out of scope for v1: it takes a MachineId (predicted hosts have one too); expanding a host to also show its attached DPUs' entries is a follow-up.
Part of #2660.
Boot-interface management used to be scattered and implicit — there was no single notion of "this machine's boot interface," so following it through discovery, ownership, and re-ingestion meant inferring it differently in each place. We've since formalized it around one type,
MachineBootInterface(a MAC paired with its vendor-native Redfish interface id), and now track it deliberately across the machine lifecycle: what exploration observed (explored_endpoints), what we predict before the first lease (predicted_machine_interfaces), the owned and authoritative row (machine_interfaces), and the pair we deliberately retain across a delete and re-ingest (retained_boot_interfaces). Four stages, one coherent model — a real step up from where this began.This command makes that model directly visible.
admin-cli machine boot-interfaces <machine-id>reads theMachineBootInterfaceat each lifecycle stage for one machine and prints them together — ASCII table (default), JSON, or YAML — so you can see and verify a machine's boot interface end to end in one place. And when something looks off, you can tell exactly which stage diverges.What it delivers:
primary_interfaceflag andrecorded_atwhere they apply.pick_boot_interface), and a flag when the stages disagree — so "is this machine's boot NIC what I expect, everywhere?" is one command.--outputformats.Mechanically: a new read-only
GetMachineBootInterfacesForge RPC and handler that gathers the four stores (the reads already exist), a small non-consumingretained_boot_interfacesread so retained rows stay visible, and themachine boot-interfacessubcommand. Tests cover the three renderers and an end-to-end read that seeds all four stores for a machine.The model is far more cohesive than it was; a single view across the stages also gives us a clean surface to keep simplifying against over time.
Out of scope for v1: it takes a MachineId (predicted hosts have one too); expanding a host to also show its attached DPUs' entries is a follow-up.
Part of #2660.