
* Pattern for nova-compute which we don't really recommend at this point, as nova wants folks to move away from it. * and cleaned up the drivers page which had older release references which don't make sense in the current day. Change-Id: I9c74ae757e2479fc44b86dc9dc4e5f6d8e146b8c Signed-off-by: Julia Kreger <juliaashleykreger@gmail.com>
4.5 KiB
Drivers, Hardware Types, and Hardware Interfaces for Ironic
Generic Interfaces
interfaces/boot interfaces/deploy
Hardware Types
drivers/idrac drivers/ilo drivers/intel-ipmi drivers/ipmitool drivers/irmc drivers/redfish drivers/snmp drivers/fake
Changing Hardware Types and Interfaces
Hardware types and interfaces are enabled in the configuration as
described in /install/enabling-drivers
. Usually, a hardware type is
configured on enrolling as described in /install/enrollment
:
baremetal node create --driver <hardware type>
Any hardware interfaces can be specified on enrollment as well:
baremetal node create --driver <hardware type> \
--deploy-interface direct --<other>-interface <other implementation>
For the remaining interfaces, the default value is assigned as
described in hardware_interfaces_defaults
. Both the hardware type
and the hardware interfaces can be changed later via the node update
API.
Changing Hardware Interfaces
Hardware interfaces can be changed by the following command:
baremetal node set <NODE> \
--deploy-interface direct \
--<other>-interface <other implementation>
The modified interfaces must be enabled and compatible with the current node's hardware type.
Changing Hardware Type
Changing the node's hardware type can pose a problem. When the
driver
field is updated, the final result must be
consistent, that is, the resulting hardware interfaces must be
compatible with the new hardware type. This will not work:
baremetal node create --name test --driver fake-hardware
baremetal node set test --driver ipmi
This is because the fake-hardware
hardware type defaults
to fake
implementations for some or all interfaces, but the
ipmi
hardware type is incompatible with them. There are
three ways to deal with this situation:
Provide new values for all incompatible interfaces, for example:
baremetal node set test --driver ipmi \ --boot-interface pxe \ --deploy-interface direct \ --management-interface ipmitool \ --power-interface ipmitool
Request resetting some of the interfaces to their new defaults by using the
--reset-<IFACE>-interface
family of arguments, for example:baremetal node set test --driver ipmi \ --reset-boot-interface \ --reset-deploy-interface \ --reset-management-interface \ --reset-power-interface
Request resetting all interfaces to their new defaults:
baremetal node set test --driver ipmi --reset-interfaces
You can still specify explicit values for some interfaces:
baremetal node set test --driver ipmi --reset-interfaces \ --deploy-interface direct
Static boot order configuration
Some hardware is known to misbehave when changing the boot device
through the BMC. To work around it you can use the noop
management interface implementation with the ipmi
and
redfish
hardware types. In this case the Bare Metal service
will not change the boot device for you, leaving the pre-configured boot
order.
For example, in the case of the pxe-boot
:
Via any available means configure the boot order on the node as follows:
Boot from PXE/iPXE on the provisioning NIC.
Warning
If it is not possible to limit network boot to only provisioning NIC, make sure that no other DHCP/PXE servers are accessible by the node.
Boot from the hard drive.
Make sure the
noop
management interface is enabled, for example:[DEFAULT] enabled_hardware_types = ipmi,redfish enabled_management_interfaces = ipmitool,redfish,noop
Change the node to use the
noop
management interface:baremetal node set <NODE> --management-interface noop