Description of problem: default_boot_interface is not set and when adding more ironic drivers, ironic complains that default_boot_interface is not set: 2021-11-18 11:08:48.225 7 ERROR ironic.conductor.base_manager [req-595f3a2f-c358-4b66-92ba-940cf34304df - - - - -] Failed to register hardware types. For hardware type 'ilo', no default value found for boot interface.: ironic.common.exception.NoValidDefaultForInterface: For hardware type 'ilo', no default value found for boot interface. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
So the configuration is, in essence, wrong. The error message could use a little refinement, since it seems to have led on to the wrong path. Enabling a hardware type doesn't override the interfaces which have been enabled and the ilo/ilo5 hardware types only supports the "ilo-ified" boot interfaces. In other words, a "default_boot_interface" is going to conflict with loading the ilo hardware type, and the ilo hardware type will not load without it's versions of the boot_interfaces on the "enabled_boot_interfaces" parameter. So, to enable the ilo or ilo5 hardware type, enabled_boot_interfaces should be set to *include* ilo-ipxe, and/or ilo-pxe. Generally we prefer ipxe based interfaces Realistically, attempting to use a default boot interface global configuration override is kind of like a giant hammer, and should not really be used unless the infrastructure operator knows *exactly* what they are doing or they have a fully heterogeneous environment. The way the capability is designed is the settings are used as an ordered list, and the union of what is enabled, and what is available helps choose the default if not explicitly defined by the request to create the node, and if all else fails, that is when it would fall back to the default_boot_interface parameter. Unfortunately, as framed, this is not a bug and this is the intended design of the software. HPE has maintained public docs on the process for enabling and explicitly using the ilo hardware type and it's advanced capabilities for some time.
The logging message is misleading and the attached change clarifies that driver config options need to be changed to reflect enabled hardware types. Its probably only justified to backport this as far as 17.
Revision of logging has merged upstream. Backports posted to upstream stable branches.
Does adding this to customer's environment make sense: ~~~ IronicEnabledHardwareTypes: ['ipmi', 'redfish', 'idrac', 'ilo'] IronicEnabledBootInterfaces: ['ilo-ipxe', 'ipxe', 'pxe'] IronicEnabledConsoleInterfaces: ['ipmitool-socat', 'ilo', 'no-console'] IronicEnabledManagementInterfaces: ['ipmitool', 'redfish', 'idrac', 'ilo'] IronicEnabledPowerInterfaces: ['ipmitool', 'redfish', 'idrac', 'ilo'] ~~~ ?
Yes, this looks like a reasonable configuration for the customer. The logging improvement is available in 17, but the THT change needs to be backported also.
Moving to modified, as the patches are is in a build for 17.0. Ready for QA verification.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Release of components for Red Hat OpenStack Platform 17.0 (Wallaby)), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:6543