Enabling IPMI double bridge support¶
This blueprint proposes ipmi double bridging support in ironic.
Currently, ironic IPMI driver(ipmitool) does not support bridging.
Many of the recent server architecture is based on distributed management. For a chassis that has “n” number of servers, the management is delegated from the core controller to many satellite controllers, which mandates the need for bridging.
When registering an baremetal node which requires bridging, the appropriate parameters should be specified to ironic IPMI power driver as follows:
The parameters can be specified based on the hardware being registered. i.e, In order to perform an double-bridge, an user can just specify ‘transit_address’ and ‘target_address’, rest is taken care by ipmi. But some hardware will mandate to specify transit_channel and target_channel, if they are using different channels.
The parameter ‘ipmi_bridging’ should specify the type of bridging required(single/dual) to access the baremetal node. If the parameter is not specified, the default value will be set to “no”
ironic node-create -d pxe_ipmitool [-i ipmi_local_address=VALUE] <-i ipmi_bridging=single> <-i ipmi_target_channel=VALUE> <-i ipmi_target_address=VALUE> …
The parameter ‘ipmi_local_address’ is optional. If the parameter is not specified, it is auto discovered by ipmitool
ironic node-create -d pxe_ipmitool [-i ipmi_local_address=VALUE] [-i ipmi_transit_local_address=VALUE] <-i ipmi_bridging=dual> <-i ipmi_transit_channel=VALUE> <-i ipmi_transit_address=VALUE> <-i ipmi_target_channel=VALUE> <-i ipmi_target_address=VALUE> …
The parameters ‘ipmi_local_address’ and ‘ipmi_transit_local_address’ are optional. If the parameters are not specified, it is auto discovered by ipmitool
Ironic IPMI driver should be modified to parse the above information and perform ipmi operations with appropriate parameters.
Data model impact¶
REST API impact¶
Driver API impact¶
Nova driver impact¶
Other end user impact¶
Depends on the number of parallel IPMI sessions that can be supported by the underlying BMC. When the sessions are exhausted, IPMI retry option can be used to get the handle of a session.
If the underlying BMC is designed for federated management, where there might be one main controller and many sub controllers, there will not be any impact. However if only one controller exists in the BMC that manages all the nodes, then the sessions might be slower when it reaches its threshold.
Other deployer impact¶
When an node which mandates bridging is being registered, provide the appropriate parameters:
- Primary assignee:
- Other contributors:
Include functionality to IPMI driver(ipmitool) to check if the underlying ipmitool utility supports bridging.
Changes to IPMI driver to parse the bridging parameters.
When a node being provisioned has bridging configuration specified, perform all ipmi operations with appropriate parameters.
Unit test cases to test IPMI driver with bridging enabled and disabled
Documentation should reflect the parameters that can be provided during registering an node to enable bridging operation.