Promote iPXE to separate boot interface¶
The iPXE boot should be promoted to a separate boot driver interface. This will simplify the code base and allow to not force global PXE vs iPXE conductor setting.
Currently setting PXE or iPXE is enforced per-conductor, and taking into account the possibility of node take-over, this choice is effectively global for the whole Ironic installation.
Due to this the current code of
PXEBoot interface is riddled
with constructs of:
if CONF.pxe.ixpe_enabled ...
Recently added or proposed changes (like
make the logic there even more complicated.
It is proposed to implement a separate iPXE boot interface, which will use the new way of serving iPXE boot scripts and boot config files directly from Ironic API as outlined in dynamic iPXE configuration spec.
The new interface will get a separate
[ipxe] config section,
[pxe]ipxe_* options should be moved following proper deprecation
policy for config options.
Current iPXE-related behavior of
PXEBoot interface should
be deprecated and eventually removed.
Continue mixing PXE and iPXE in single driver interface and setting iPXE vs PXE globally.
Data model impact¶
State Machine Impact¶
REST API impact¶
Client (CLI) impact¶
“openstack baremetal” CLI¶
RPC API impact¶
Driver API impact¶
Nova driver impact¶
Other end user impact¶
Other deployer impact¶
A new config section
[ipxe]will be added, with most of the ipxe_* options copied from current
ipxe_removed from option names). By the virtue of
oslo_configlibrary, the new options will be backward compatible with old, deprecated ones, using their values when not set explicitly.
This change has no immediate effect. Enabling it is a conscious choice of the operator:
a driver utilizing this new
iPXEBootboot interface must be composed
such driver must be assigned to the node
- Primary assignee:
pshchelo (Pavlo Shchelokovskyy)
create a new
identify and refactor code that is common for
register this driver as entry point for
add it to list of boot interfaces enabled by default in ironic config (
add appropriate documentation
No specific coverage seems to be needed apart from enabling a driver that uses this new proposed boot interface at least on one gate job.
Upgrades and Backwards Compatibility¶
The feature has no immediate effect on existing installation as it must be manually enabled first by enabling the interface and composing an appropriate driver with this boot interface.
Existing drivers do not depend on this feature in any way.
It is also proposed to deprecate and eventually remove iPXE capabilities from the PXEBoot interface.
Chain-loading an iPXE-capable boot-loader will still be supported by iPXEBoot driver to support older/dumber/buggy hardware.
Document new driver interface and its usage.