Define idrac Hardware Type Support of Redfish Interfaces¶
Operators need the ability to configure Ironic to use Redfish to manage Dell EMC bare metal servers, and be assured it:
offers a means of incrementally increasing the use of Redfish as Ironic’s support, the standard, and Dell EMC service implementations evolve,
provides all the
idrachardware type functionality they have relied on,
works and will continue to,
is supported by the vendor and community, and
can offer Dell EMC value added.
This specification suggests the
idrac hardware type provides that.
Expanding on what the introductory paragraph describes above, several use cases can be envisioned. While this specification enables them, it may turn out only some will find practical use among operators. That could be driven by many factors, including an existing versus greenfield deployment, operator comfort level with Redfish versus WS-Man, maturity of the protocol implementations, availability of needed functionality across Redfish and WS-Man, requirement for vendor value added, operational plans and schedules, among others.
Here they are. Note that except for the first two, they can be used in combination to configure a single Dell EMC bare metal server.
An Admin User has a Dell EMC bare metal server and uses only WS-Man to manage it.
An Admin User has a Dell EMC bare metal server and uses only Redfish to manage it.
An Admin User has a Dell EMC bare metal server and uses both Redfish and WS-Man to manage it. When both offer the needed functionality, either is used.
An Admin User has a Dell EMC bare metal server and uses both Redfish and WS-Man to manage it. Ironic’s ability to manage the server is maximized.
An Admin User has a Dell EMC bare metal server and uses both Redfish and WS-Man to manage it. Vendor value added, which is available from only one or both, is used.
idrac hardware type is the Ironic driver intended for use with Dell EMC
bare metal servers equipped with an integrated Dell Remote Access Controller
(iDRAC) baseboard management controller (BMC). To date, all the out-of-band
(OOB) management protocol-dependent interface implementations
supported use the WS-Man protocol to interact with the iDRAC. Those implement
interfaces. Like the hardware type, they are named
idrac. They rely on
python-dracclient’s WS-Man client.
Operators also have the option to use the generic, vendor-independent
redfish hardware type with Dell EMC bare metal servers that have an iDRAC
that supports the Redfish protocol.
redfish’s supported OOB protocol-
dependent interface implementations use the Redfish protocol to interact with
the BMC. Those implement the
power hardware interfaces. Again, like the hardware type, they are named
redfish. They rely on sushy’s Redfish client. Importantly, while some
of those work with the iDRAC, including
power, not all
of them do.
redfish hardware type enables managing servers compliant with the
Redfish protocol. However, it is relatively new, and the protocol standard has
been evolving, along with its implementations by hardware vendors such as Dell
EMC. As is common among standards, there is a difference between compliance and
interoperability. For example, the Redfish
bios interface implementation
has not worked with the iDRAC because of client and server protocol
While there is much functional overlap between the interface implementations
supported by the
redfish hardware types, it is not complete.
idrac supports a
raid interface implementation and only
bios. Also, the optional hardware interface
functionality available in the
implementations can differ. For example, while the
management hardware interface first introduced optional boot mode
idrac does not offer that, yet. Therefore, those two
hardware types are not perfect substitutes for one another.
Dell EMC wants to be able to offer its customers vendor value added as supported by the Redfish standard, like it has done through WS-Man. That benefits operators by making available features and functionality that has not yet been standardized. Dell EMC can be more responsive to its customers’ needs and differentiate itself in the market.
With this specification, we are going to achieve the goal of promoting and accelerating the adoption of Redfish by operators with Dell EMC bare metal servers.
The following is considered outside the scope of this specification:
Support a node configuration with a mix of Redfish and WS-Man
powerinterface implementations. The legacy
idracimplementations of the
powerhardware interfaces interact to set the boot device. It is not clear there is a compelling need to accommodate that in a mixed Redfish and WS-Man configuration.
The following TripleO command can be used to register and configure nodes for their deployment with Ironic:
openstack overcloud node import instackenv.json
See the TripleO register nodes documentation. It sets properties in a node’s
driver_infofield which are required by its driver. Presently, when the node’s driver is
idrac, those are the properties –
drac_password– needed by the WS-Man interface implementations
idrachas supported. See the iDRAC driver documentation.
The Redfish interface implementations need similar, but different, properties in the
redfish_password. See the Redfish driver documentation.
Changing that TripleO command to set both the Redfish and WS-Man properties in a node’s
driver_infofield when its
idracis beyond the scope of this specification. That will be addressed by a TripleO project blueprint.
idrachardware type support of IPMI interface implementations. That could be done as a follow-on to this.
This specification proposes to solve the problem it describes by changing the
idrac hardware type. Since the Ironic Driver composition reform, we have
been allowed to have “one vendor driver with options configurable per node
instead of many drivers for every vendor.”  The reform’s goals include
* Make vendors in charge of defining a set of supported interface
implementations in priority order
* Allow vendors to guarantee that unsupported interface implementations will
not be used with hardware types they define. This is done by having a
hardware type list all interfaces it supports.
Implementing the solution in the
idrac hardware type contributes toward
making it the one Dell EMC driver for its bare metal servers with iDRACs and
their value added implementations of the IPMI, Redfish, and WS-Man management
protocols. It also aligns with the goals of the reform. That is what operators
have come to expect.
Here are the details of the proposal.
Define two new groups of interface implementations with entrypoints named
idrac-redfishentrypoints refer to Redfish interface implementations which are compatible with the iDRAC, presently those of the
powerhardware interfaces. The
idrac-wsmanentrypoints are new names for the legacy
idracentrypoints. The legacy
idracentrypoints are left unchanged. For example:
ironic.hardware.interfaces.management = ... idrac = ironic.drivers.modules.drac.management:DracManagement idrac-redfish = ironic.drivers.modules.drac.management:DracRedfishManagement idrac-wsman = ironic.drivers.modules.drac.management:DracWSManManagement ... redfish = ironic.drivers.modules.redfish.management:RedfishManagement
idrachardware type support for the
idraccontinues to have the highest priority by being first in its
<INTERFACE>is a type of hardware interface:
power, etc. For example:
class IDRACHardware(generic.GenericHardware): ... @property def supported_management_interfaces(self): return [management.DracManagement, management.DracWSManManagement, management.DracRedfishManagement] ...
The property uses classes, not instances nor entrypoint names. The example assumes the required modules are imported.
idrac-redfishentrypoints are defined by new Python classes, because using the generic, vendor-independent Redfish classes would make the
redfishentrypoints synonyms for
idrac-redfishand supported. A later requirement to change the name of an entrypoint’s Python class to resolve a Dell EMC-specific incompatibility or introduce vendor value added, which would eliminate support for
redfish, could be a breaking change. The new Python classes are derived from the generic, vendor-independent Redfish classes.
idrac-wsmanentrypoints are defined by new Python classes. Those classes are created by renaming the classes for the legacy
<INTERFACE>refers to a type of hardware interface:
Drac<INTERFACE>classes are redefined by simply deriving them from the new
DracWSMan<INTERFACE>classes. For example:
class DracManagement(DracWSManManagement): pass
That makes the legacy
Drac<INTERFACE>classes aliases for the new
DracWSMan<INTERFACE>classes. Any bug fixes or features added to the WS-Man interface implementations are available from both the
idrac-wsmanentrypoints. Having separate classes for the two groups of entrypoints makes it possible to subsequently add logic that implements deprecation of the legacy
idracentrypoints by emitting a log message and similar.
We could change the lowest layer of
python-dracclientto support Redfish, in addition to WS-Man. However, we expect it would be challenging to provide
python-dracclientAPIs and workflows which abstract the very different Redfish and WS-Man technologies. Redfish’s interface is RESTful, while WS-Man is a Simple Object Access Protocol (SOAP). APIs and workflows would likely need to be changed or newly defined. That would require substantial modification of the existing
We could maintain the status quo split of the
idrachardware type for WS-Man and
redfishhardware type for Redfish. However, that would not promote and accelerate the use of Redfish among operators with Dell EMC bare metal servers today, because
redfishdoes not offer everything
idracdoes. That also would not support resolving Dell EMC vendor- specific incompatibilities with the generic, vendor-independent
redfishhardware type nor using Redfish to introduce vendor value added.
We could let the
redfishinterface implementations use Redfish OEM extensions to address vendor-specific incompatibilities and introduce vendor value added. However, that seems inconsistent with the intent that they be generic and vendor-independent.
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 deployer can add
enabled_power_interfacesoptions to enable those new interface implementations.
A deployer can add
enabled_vendor_interfacesto enable those new interface implementations.
A deployer must specify properties in the node’s
driver_infofield that are needed by Redfish interface implementations, including
redfish_password, to use the
idrac-redfishinterface implementations. That is in addition to the legacy properties the
idrachardware type has needed in
openstack baremetal node create --driver idrac --driver-info \ drac_address=184.108.40.206 --driver-info drac_username=admin --driver-info \ drac_password=password --driver_info redfish_address=https://220.127.116.11 \ --driver-info redfish_system_id=/redfish/v1/Systems/System.Embedded.1 \ --driver-info redfish_username=admin --driver-info \ redfish_password=password
A deployer can specify the new
idrac-wsmaninterface implementations on node enrollment:
openstack baremetal node create --driver idrac ... --management-interface \ idrac-wsman --power-interface idrac-wsman ...
They can also be set by the following command:
openstack baremetal node set <NODE> --management-interface idrac-redfish \ --power-interface idrac-redfish
They must be enabled as described above.
- Primary assignee:
- Other contributors:
Define two new groups of interface implementations with entrypoints named
idrachardware type support for the
Integration test the changes against Dell EMC bare metal servers.
Modify the Dell EMC Ironic third-party continuous integration (CI) to cover supported configurations added by this specification.
Update the iDRAC driver documentation.
This specification is related to the Driver composition reform.
It specifically targets Dell EMC bare metal servers equipped with an iDRAC and
managed by the
idrac hardware type.
This is not testable in the gate given current limitations on the availability of the specific hardware required.
The mitigation plan is to add coverage to the Dell EMC Ironic third-party CI for supported configurations added by this specification that we expect to be common.
Upgrades and Backwards Compatibility¶
This change is designed to be backwards compatible. The legacy
interface implementation entrypoints will be supported for at least some time.
A separate story will cover their deprecation.
We will recommend switching to the appropriate new
idrac-wsman interface implementation entrypoints as soon as it is possible.
The iDRAC driver documentation is updated to:
describe switching from the legacy
idracinterface implementation entrypoints to the new
reflect the changes to the supported interface implementations, and
inform that a node configuration with a mix of Redfish and WS-Man
powerinterface implementations is not supported.
- OpenStack software projects:
- Related Ironic specifications: