HTTPBoot¶
https://bugs.launchpad.net/ironic/+bug/2032380
A long sought after feature in Ironic is to boot a node from a single HTTP URL. Except, there is more than one flavor of this functionality.
A first flavor is very virtual media like where we ask the Baseboard management controller to boot the machine from a URL. The exact details are vendor specific, but in essence UEFI firmware boots the OS from the URL.
The second flavor is very similar to PXE booting using DHCP, however the primary difference is through the use of a vendor class of “HTTPClient” is utilized instead of “PXEClient”. The funny thing, IPv6 network boot requires the same DHCP response in the form of a URL for the bootfile-url.
The reason to note both is they are both very similar, and both can be tested in our CI at this point. Previously we deferred implementation of the DHCP path because a lack of ability to test that in CI, but that is no longer a constraint of late 2023.
Implementing both would be relatively easy and very beneficial for the operator ecosystem, while also allowing for the navigation of the security and NAT incompatability issues which exist with TFTP.
Problem description¶
Infrastructure operators need reliable, and realtively secure means of conveying bootloaders and initial artifacts to remote machines.
Ironic’s historical answer has been to utilize virtual media.
But not all hardware supports virutal media, and emulating a block device is not exactly the simplest thing once you boot an operating system. A helpful aspect with UEFI and the evolution of systems is now we have facilities in Baseboard management controllers and even UEFI base firmware support retrieving initial boot payload from a remote system using HTTP(s).
Proposed change¶
Given the similarity, it makes sense to implement support for both the BMC oriented path and the DHCP oriented path as part of single effort.
The greater benefit for implementing the DHCP oriented path is we can also extend this functionality to our downstream consumers with minimal effort.
BMC Path¶
Update sushy-tools to support mapping cals to utilize a HTTP next boot URL to the virutal media driver code. Functionally this is similar, as there appears to be no means to inject the hint to boot from the URL into libvirt.
Update sushy to support requesting to boot a node from a HTTP URL.
Create a new
redfish-http-url
boot interface, namedRedfishHTTPBoot
BootInterface class based upon the underlying classRedfishVirtualMediaBoot
. In this class, replace_insert_vmedia
, and_eject_vmedia
class. In essence these methods would perform the needful calls to the BMC to perform actions such as settingBootSourceOverrideEnabled
to “Once”,BootSourceOverrideMode
to “UEFI”,BootSourceOverrideTarget
to “UefiHttp”, and finallyHttpBootUri
to the ISO file we wish to boot.
Constraints:
Limited to UEFI.
Note
We may wish to retool some of the internals of the RedfishVirtualMediaBoot class for our implementation sanity.
Note
This interface with the BMCs is modeled around use of an ISO image as a boot source, where as the DHCP path is modeled upon a bootloader, much like iPXE.
DHCP Path¶
Determine if we need to modify the
neutron-dhcp-agent
.Create an
httpboot
BootInterface based upon the existingpxe
interface code base, and wire through a flag which is set by the PXE utils invocation of the DHCP code base, to signal the use of an HTTP(S) URL to the conductor. Specifically it would take the form of a flag on the pxe_utils methodprepare_instance_pxe_config
which would be supplied to thedhcp_options_for_instance
method call in the same file. Likely as simple aspxe_base
looking for a feature flag on the BootInterface class.
Note
We may wish to make an iPXE specific version of the boot interface as well, which is also already handled by a capabilities feature flag. A separation would enable Grub and iPXE use concurrently.
Alternatives¶
We could limit scope, but there really are not any alternatives, and both paths provide a great deal of functionality and benefit to users of Ironic.
Data model impact¶
None
State Machine Impact¶
None
REST API impact¶
None
Client (CLI) impact¶
“openstack baremetal” CLI¶
None, this is entirely a server side capability/configuration.
“openstacksdk”¶
None, this is entirely a server side capability/configuration.
RPC API impact¶
None
Driver API impact¶
No changes to the Driver API are anticipated, although this change functionally proposes two or three different BootInterfaces to be created.
Nova driver impact¶
None
Ramdisk impact¶
None. Booting the ramdisk would take the existing code paths with slight deviation where applicable for each driver case.
Security impact¶
The overall security posture of deployments could improve with these capabilities. Specifically UEFI firmware can boot an ISO or first stage bootloader over HTTPS.
Other end user impact¶
None
Scalability impact¶
None anticipated.
Performance Impact¶
None anticipated.
Other deployer impact¶
Deployers interested in using this functionality will have expanded operational and security capabilities which are in-line with established interfaces and data models in Ironic.
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
Julia (TheJulia) Kreger <juliaashleykreger@gmail.com>
- Other contributors:
Volunteers welcome!
Work Items¶
Add support to sushy and sushy-tools for the URL boot operation.
Add support to pxe_utils logic to generate a URL boot response payload, and set that based upon a driver feature/capability flag.
Compose lots of documentation.
Create tempest suite to execise both modes of boot operations.
Dependencies¶
IF we need to apply DHCP server configuration, similar to PXE/IPXE, chain loading attributes, then we will need to engage the Neutron developers.
Testing¶
The ideal path would be to create a single integration suite test in the ironic-tempest-plugin to set a node to utilize both interfaces, and toggle the nodes through a clean step, which would prove the interfaces work as we expect.
Upgrades and Backwards Compatibility¶
No issues are anticipated here.
Documentation Impact¶
We will likely need to compose more documentation than code in every case of these interface.