The recommendation for Spine-and-Leaf architectures is to use Virtual Media, because this simplifies the required DHCP configuration. It is possible to configure external DHCP to provide the options for nodes to network boot, but virtual-media is far easier.

We should document and test the below, in the prioritezed order #1 prio-1 and so on.

1. Use Metal3 with Virtual Media where localized DHCP/SLAAC supplies base connectivity which is disjointed from Metal3. DHCP/SLAAC is used for IPA, but doesn’t have to be used in the final configuration i.e the deployed dataplane node.
2. Use Metal3 with Virtual Media, with sufficient configuration is embedded in the virtual media ramdisk to facilitate deployment.
3. Use Metal3 with localized DHCP with appropriate records to boot to Metal3’s management. This just consists of appropriate static dhcp server configuration, which was a similar overhead to configuring relaying for most customers in the past. This is best documented as a KB Article instead of documentation, as it is not the preferred path, and the Metal3 TFTP/HTTP boot endpoint contents are not static between releases. (The DHCP configuration may need to be updated, because the filenames on TFTP/HTTP services in OpenShift is not a "stable API".

NOTE: We do not know if any of these usecases will require additional development work. If we find that this is the case, open stories in this epic.