Problem
Today every server power-on in metal-operator is a network boot. The operator sets a one-time network boot override on the BMC for every power cycle, regardless of context, the discovery probe, the reserved/provisioning boot, and reboots of an already-provisioned server.
There is no notion that a boot image is something: that a UKI is an HTTP-boot image, or that a kernel/initramfs is a PXE image, or that an installed OS on disk is a disk-boot image. The image is an opaque string, and the boot method is an operator decision that is always a network boot. The result:
- The network boot override the operator sets is fixed to PXE. HTTP Boot is only reachable indirectly, by configuring the BIOS boot order, not as something the operator drives for a specific boot. Virtual Media and disk boot are not reachable at all.
- The image and the boot behavior can disagree: nothing checks that the image actually contains the artifacts the chosen boot method expects. A PXE boot against a UKI-only image, or an HTTP boot against a kernel/initramfs image, fails late and silently.
- Reboots of a provisioned server are still network boots, fighting the BIOS boot order and risking re-provisioning loops.
- The actual boot method is determined by BIOS boot order, DHCP, and the boot-operator, none of which the operator can reason about, because the image carries no boot semantics.
On top of that, the boot logic is welded into the metal-operator. It is not something another consumer could pick up and use to boot a server.
What we need
A reusable component (a server boot tool) that knows how to boot a server: given a server and a boot image, it resolves the boot mode from the image's own boot identity and drives the boot accordingly (network boot vs disk boot), instead of the boot method being decided up front by the caller and hardcoded to a single
network-boot method.
The image is the source of truth for what the boot actually is. The tool reads the image's boot identity and selects the right boot path from it. The metal-operator becomes one consumer of this component; other consumers should be able to use it outside of the metal-operator without taking the operator's reconcile machinery along.
Outlook
Once the image is the source of truth for the boot mode, the same mechanism extends to further boot methods beyond network and disk boot. In particular, ISO boot via Redfish Virtual Media becomes possible: an image declaring itself as an ISO artifact would map to a Virtual Media boot, with no new concept in the tool, just a new image identity and its corresponding boot path.
References
Problem
Today every server power-on in
metal-operatoris a network boot. The operator sets a one-time network boot override on the BMC for every power cycle, regardless of context, the discovery probe, the reserved/provisioning boot, and reboots of an already-provisioned server.There is no notion that a boot image is something: that a UKI is an HTTP-boot image, or that a kernel/initramfs is a PXE image, or that an installed OS on disk is a disk-boot image. The image is an opaque string, and the boot method is an operator decision that is always a network boot. The result:
On top of that, the boot logic is welded into the
metal-operator. It is not something another consumer could pick up and use to boot a server.What we need
A reusable component (a server boot tool) that knows how to boot a server: given a server and a boot image, it resolves the boot mode from the image's own boot identity and drives the boot accordingly (network boot vs disk boot), instead of the boot method being decided up front by the caller and hardcoded to a single
network-boot method.
The image is the source of truth for what the boot actually is. The tool reads the image's boot identity and selects the right boot path from it. The metal-operator becomes one consumer of this component; other consumers should be able to use it outside of the metal-operator without taking the operator's reconcile machinery along.
Outlook
Once the image is the source of truth for the boot mode, the same mechanism extends to further boot methods beyond network and disk boot. In particular, ISO boot via Redfish Virtual Media becomes possible: an image declaring itself as an ISO artifact would map to a Virtual Media boot, with no new concept in the tool, just a new image identity and its corresponding boot path.
References