11 KiB
Enabling drivers and hardware types
Introduction
The Bare Metal service delegates actual hardware management to
drivers. Starting with the Ocata release, two types of
drivers are supported: classic drivers (for example,
pxe_ipmitool, agent_ilo, etc.) and the newer
hardware types (for example, generic redfish and
ipmi or vendor-specific ilo and
irmc).
Drivers, in turn, consist of hardware interfaces: sets of functionality dealing with some aspect of bare metal provisioning in a vendor-specific way. Classic drivers have all hardware interfaces hardcoded, while hardware types only declare which hardware interfaces they are compatible with.
Please refer to the driver composition reform specification for technical details behind hardware types.
From API user's point of view, both classic drivers and
hardware types can be assigned to the driver field
of a node. However, they are configured differently.
Enabling hardware types
Hardware types are enabled in the configuration file of the
ironic-conductor service by setting the
enabled_hardware_types configuration option, for
example:
[DEFAULT]
enabled_hardware_types = ipmi,redfishHowever, due to their dynamic nature, they also require configuring enabled hardware interfaces.
Note
All available hardware types and interfaces are listed in setup.cfg file in the source code tree.
Enabling hardware interfaces
There are several types of hardware interfaces:
- boot
-
manages booting of both the deploy ramdisk and the user instances on the bare metal node. Boot interface implementations are often vendor specific, and can be enabled via the
enabled_boot_interfacesoption:[DEFAULT] enabled_hardware_types = ipmi,ilo enabled_boot_interfaces = pxe,ilo-virtual-mediaBoot interfaces with
pxein their name requireconfigure-pxe. - console
-
manages access to the serial console of a bare metal node. See Configuring Web or Serial Console for details.
- deploy
-
defines how the image gets transferred to the target disk.
- With
iscsideploy method the deploy ramdisk publishes node's hard drive as an iSCSI share. The ironic-conductor then copies the image to this share. Requiresconfigure-iscsi. - With
directdeploy method, the deploy ramdisk fetches the image from an HTTP location (object storage temporary URL or user-provided HTTP URL).
[DEFAULT] enabled_hardware_types = ipmi,redfish enabled_deploy_interfaces = iscsi,direct - With
- inspect
-
implements fetching hardware information from nodes. Can be implemented out-of-band (via contacting the node's BMC) or in-band (via booting a ramdisk on a node). The latter implementation is called
inspectorand uses a separate service called ironic-inspector. Example:[DEFAULT] enabled_hardware_types = ipmi,ilo,irmc enabled_inspect_interfaces = ilo,irmc,inspectorSee inspection documentation for more details.
- management
-
provides additional hardware management actions, like getting or setting boot devices. This interface is usually vendor-specific, and its name often matches the name of the hardware type (with
ipmitoolbeing a notable exception). For example:[DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_management_interfaces = ipmitool,redfish,ilo,irmcUsing
ipmitoolrequiresconfigure-ipmi. See driver-specific documentation for required configuration of each driver. - network
-
connects/disconnects bare metal nodes to/from virtual networks. This is the only interface that is also pluggable for classic drivers. See
configure-tenant-networksfor more details. - power
-
runs power actions on nodes. Similar to the management interface, it is usually vendor-specific, and its name often matches the name of the hardware type (with
ipmitoolbeing again an exception). For example:[DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_power_interfaces = ipmitool,redfish,ilo,irmcUsing
ipmitoolrequiresconfigure-ipmi. See driver-specific documentation for required configuration of each driver. - raid
-
manages building and tearing down RAID on nodes. Similar to inspection, it can be implemented either out-of-band or in-band (via
agentimplementation). See RAID documentation for details.[DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_raid_interfaces = agent,no-raid - vendor
-
is a place for vendor extensions to be exposed in API. See vendor methods documentation for details.
[DEFAULT] enabled_hardware_types = ipmi,redfish,ilo,irmc enabled_vendor_interfaces = ipmitool,no-vendor
Here is a complete configuration example, enabling two generic protocols, IPMI and Redfish, with a few additional features:
[DEFAULT]
enabled_hardware_types = ipmi,redfish
enabled_boot_interfaces = pxe
enabled_console_interfaces = ipmitool-socat,no-console
enabled_deploy_interfaces = iscsi,direct
enabled_inspect_interfaces = inspector
enabled_management_interfaces = ipmitool,redfish
enabled_network_interfaces = flat,neutron
enabled_power_interfaces = ipmitool,redfish
enabled_raid_interfaces = agent
enabled_vendor_interfaces = ipmitool,no-vendorNote that some interfaces have implementations named
no-<TYPE> where <TYPE> is the
interface type. These implementations do nothing and return errors when
used from API.
Hardware interfaces in multi-conductor environments
When enabling hardware types and their interfaces, make sure that for every enabled hardware type, the whole set of enabled interfaces matches for all conductors. However, different conductors can have different hardware types enabled.
For example, you can have two conductors with the following configuration respectively:
[DEFAULT]
enabled_hardware_types = ipmi
enabled_deploy_interfaces = direct
enabled_power_interfaces = ipmitool
enabled_management_interfaces = ipmitool[DEFAULT]
enabled_hardware_types = redfish
enabled_deploy_interfaces = iscsi
enabled_power_interfaces = redfish
enabled_management_interfaces = redfishBut you cannot have two conductors with the following configuration respectively:
[DEFAULT]
enabled_hardware_types = ipmi,redfish
enabled_deploy_interfaces = direct
enabled_power_interfaces = ipmitool,redfish
enabled_management_interfaces = ipmitool,redfish[DEFAULT]
enabled_hardware_types = redfish
enabled_deploy_interfaces = iscsi
enabled_power_interfaces = redfish
enabled_management_interfaces = redfishThis is because the redfish hardware type will have
different enabled deploy interfaces on these conductors. It
would have been fine, if the second conductor had
enabled_deploy_interface=direct instead of
iscsi.
This situation is not detected by the Bare Metal service, but it can cause inconsistent behavior in the API, when node functionality will depend on which conductor it gets assigned to.
Note
We don't treat it as an error, because such temporary inconsistency is inevitable during a rolling upgrade or a configuration update.
Configuring interface defaults
When a user does not provide an explicit value for one of interfaces
(when creating a node or updating its driver), the default value is
calculated as described in hardware_interfaces_defaults. An operator can override
the defaults for any interfaces by setting one of options named
default_<IFACE>_interface, where
<IFACE> is the interface name. For example:
[DEFAULT]
default_deploy_interface = direct
default_network_interface = neutronThis configuration forces the default deploy interface to be
direct and the default network interface to be
neutron for all hardware types.
The defaults are calculated and set on a node when creating it or updating its hardware type. Thus, changing these configuration options has no effect on existing nodes.
Warning
The default interface implementation has to be configured the same way across all conductors in the cloud, except maybe for a short period of time during an upgrade or configuration update.
Warning
These options should be used with care. If a hardware type does not support the provided default implementation, its users will have to always provide an explicit value for this interface when creating a node.
Enabling classic drivers
Classic drivers are enabled in the configuration file of the
ironic-conductor service by setting the
enabled_drivers configuration option, for example:
[DEFAULT]
enabled_drivers = pxe_ipmitool,pxe_ilo,pxe_dracThe names in this comma-separated list are entry point names of the drivers. They have to be available at conductor start-up, and all dependencies must be installed locally. For example,
- drivers starting with
pxeand some drivers starting withagentrequireconfigure-pxe, - drivers starting with
pxeor havingiscsiin their name requireconfigure-iscsi, - drivers ending with
ipmitoolrequireconfigure-ipmi.
See driver-specific documentation for required configuration of each driver.