Add spec for idrac HW type support of Redfish
This adds a specification for defining idrac hardware type support of Redfish interface implementations. Story: 2004592 Task: 28470 Change-Id: I9f2b868b93f2d527f6f1352dbdca29274ff4b851
This commit is contained in:
parent
9403efa6da
commit
0d139e3567
|
@ -0,0 +1,495 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
========================================================
|
||||||
|
Define idrac Hardware Type Support of Redfish Interfaces
|
||||||
|
========================================================
|
||||||
|
|
||||||
|
https://storyboard.openstack.org/#!/story/2004592
|
||||||
|
|
||||||
|
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,
|
||||||
|
* delivers management protocol choice among those supported by Dell EMC --
|
||||||
|
Intelligent Platform Management Interface (IPMI_), Redfish, and Web Services
|
||||||
|
Management (WS-Man_),
|
||||||
|
* provides all the ``idrac`` hardware 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.
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Use cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Background
|
||||||
|
----------
|
||||||
|
|
||||||
|
The ``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 ``idrac`` has
|
||||||
|
supported use the WS-Man protocol to interact with the iDRAC. Those implement
|
||||||
|
the ``inspect``, ``management``, ``power``, ``raid``, and ``vendor`` hardware
|
||||||
|
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 ``bios``, ``inspect``, ``management``, and
|
||||||
|
``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 ``management`` and ``power``, not all
|
||||||
|
of them do.
|
||||||
|
|
||||||
|
The ``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
|
||||||
|
implementation incompatibility.
|
||||||
|
|
||||||
|
While there is much functional overlap between the interface implementations
|
||||||
|
supported by the ``idrac`` and ``redfish`` hardware types, it is not complete.
|
||||||
|
Only ``idrac`` supports a ``raid`` interface implementation and only
|
||||||
|
``redfish`` supports ``bios``. Also, the optional hardware interface
|
||||||
|
functionality available in the ``idrac`` and ``redfish`` interface
|
||||||
|
implementations can differ. For example, while the ``redfish`` implementation
|
||||||
|
of the ``management`` hardware interface first introduced optional boot mode
|
||||||
|
functionality, ``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.
|
||||||
|
|
||||||
|
Goal
|
||||||
|
----
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
Non-goals
|
||||||
|
---------
|
||||||
|
|
||||||
|
The following is considered outside the scope of this specification:
|
||||||
|
|
||||||
|
* Support a node configuration with a mix of Redfish and WS-Man ``management``
|
||||||
|
and ``power`` interface implementations. The legacy ``idrac`` implementations
|
||||||
|
of the ``management`` and ``power`` hardware 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_info`` field which are required by its driver. Presently,
|
||||||
|
when the node's driver is ``idrac``, those are the properties --
|
||||||
|
``drac_address``, ``drac_username``, and ``drac_password`` -- needed by the
|
||||||
|
WS-Man interface implementations ``idrac`` has supported. See the
|
||||||
|
`iDRAC driver`_ documentation.
|
||||||
|
|
||||||
|
The Redfish interface implementations need similar, but different, properties
|
||||||
|
in the ``driver_info`` field, including ``redfish_address``,
|
||||||
|
``redfish_system_id``, ``redfish_username``, and ``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_info`` field when its ``driver`` is ``idrac`` is beyond
|
||||||
|
the scope of this specification. That will be addressed by a TripleO project
|
||||||
|
blueprint.
|
||||||
|
|
||||||
|
* Define ``idrac`` hardware type support of IPMI interface implementations.
|
||||||
|
That could be done as a follow-on to this.
|
||||||
|
|
||||||
|
Solution
|
||||||
|
--------
|
||||||
|
|
||||||
|
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." [#f1]_ The reform's goals include
|
||||||
|
[#f2]_::
|
||||||
|
|
||||||
|
* 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-redfish`` and ``idrac-wsman``. The ``idrac-redfish`` entrypoints
|
||||||
|
refer to Redfish interface implementations which are compatible with the
|
||||||
|
iDRAC, presently those of the ``management`` and ``power`` hardware
|
||||||
|
interfaces. The ``idrac-wsman`` entrypoints are new names for the legacy
|
||||||
|
``idrac`` entrypoints. The legacy ``idrac`` entrypoints 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
|
||||||
|
|
||||||
|
|
||||||
|
* Declare ``idrac`` hardware type support for the ``idrac``, ``idrac-redfish``,
|
||||||
|
and ``idrac-wsman`` interface implementations. ``idrac`` continues to have
|
||||||
|
the highest priority by being first in its
|
||||||
|
``supported_<INTERFACE>_interfaces`` lists. Here ``<INTERFACE>`` is a type of
|
||||||
|
hardware interface: ``inspect``, ``management``, ``power``, etc. For
|
||||||
|
example::
|
||||||
|
|
||||||
|
class IDRACHardware(generic.GenericHardware):
|
||||||
|
...
|
||||||
|
@property
|
||||||
|
def supported_management_interfaces(self):
|
||||||
|
return [management.DracManagement, management.DracWSManManagement,
|
||||||
|
management.DracRedfishManagement]
|
||||||
|
...
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
The property uses classes, not instances nor entrypoint names. The example
|
||||||
|
assumes the required modules are imported.
|
||||||
|
|
||||||
|
* New ``idrac-redfish`` entrypoints are defined by new Python classes, because
|
||||||
|
using the generic, vendor-independent Redfish classes would make the
|
||||||
|
``redfish`` entrypoints synonyms for ``idrac-redfish`` and 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.
|
||||||
|
|
||||||
|
* New ``idrac-wsman`` entrypoints are defined by new Python classes. Those
|
||||||
|
classes are created by renaming the classes for the legacy ``idrac``
|
||||||
|
entrypoints from ``Drac<INTERFACE>`` to ``DracWSMan<INTERFACE>``. Here
|
||||||
|
``<INTERFACE>`` refers to a type of hardware interface: ``Inspect``,
|
||||||
|
``Management``, ``Power``, etc.
|
||||||
|
|
||||||
|
The legacy ``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`` and
|
||||||
|
``idrac-wsman`` entrypoints. Having separate classes for the two groups of
|
||||||
|
entrypoints makes it possible to subsequently add logic that implements
|
||||||
|
deprecation of the legacy ``idrac`` entrypoints by emitting a log message and
|
||||||
|
similar.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
* We could change the lowest layer of ``python-dracclient`` to support
|
||||||
|
Redfish, in addition to WS-Man. However, we expect it would be challenging
|
||||||
|
to provide ``python-dracclient`` APIs 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 ``idrac`` interface implementations.
|
||||||
|
|
||||||
|
* We could maintain the status quo split of the ``idrac`` hardware type for
|
||||||
|
WS-Man and ``redfish`` hardware type for Redfish. However, that would not
|
||||||
|
promote and accelerate the use of Redfish among operators with Dell EMC
|
||||||
|
bare metal servers today, because ``redfish`` does not offer everything
|
||||||
|
``idrac`` does. That also would not support resolving Dell EMC vendor-
|
||||||
|
specific incompatibilities with the generic, vendor-independent ``redfish``
|
||||||
|
hardware type nor using Redfish to introduce vendor value added.
|
||||||
|
|
||||||
|
* We could let the ``redfish`` interface 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
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
State Machine Impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Client (CLI) impact
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
"ironic" CLI
|
||||||
|
~~~~~~~~~~~~
|
||||||
|
None
|
||||||
|
|
||||||
|
"openstack baremetal" CLI
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
None
|
||||||
|
|
||||||
|
RPC API impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Driver API impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Nova driver impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Ramdisk impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Scalability impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
* A deployer can add ``idrac-redfish`` to the ``enabled_management_interfaces``
|
||||||
|
and ``enabled_power_interfaces`` options to enable those new interface
|
||||||
|
implementations.
|
||||||
|
|
||||||
|
* A deployer can add ``idrac-wsman`` to the ``enabled_inspect_interfaces``,
|
||||||
|
``enabled_management_interfaces``, ``enabled_power_interfaces``,
|
||||||
|
``enabled_raid_interfaces``, and ``enabled_vendor_interfaces`` to enable
|
||||||
|
those new interface implementations.
|
||||||
|
|
||||||
|
* A deployer must specify properties in the node's ``driver_info`` field that
|
||||||
|
are needed by Redfish interface implementations, including
|
||||||
|
``redfish_address``, ``redfish_system_id``, ``redfish_username``, and
|
||||||
|
``redfish_password``, to use the ``idrac-redfish`` interface implementations.
|
||||||
|
That is in addition to the legacy properties the ``idrac`` hardware type has
|
||||||
|
needed in ``driver_info`` -- ``drac_address``, ``drac_username``, and
|
||||||
|
``drac_password``.
|
||||||
|
::
|
||||||
|
|
||||||
|
openstack baremetal node create --driver idrac --driver-info \
|
||||||
|
drac_address=1.2.3.4 --driver-info drac_username=admin --driver-info \
|
||||||
|
drac_password=password --driver_info redfish_address=https://1.2.3.4 \
|
||||||
|
--driver-info redfish_system_id=/redfish/v1/Systems/System.Embedded.1 \
|
||||||
|
--driver-info redfish_username=admin --driver-info \
|
||||||
|
redfish_password=password
|
||||||
|
|
||||||
|
See the `Redfish driver`_ documentation, `iDRAC driver`_
|
||||||
|
documentation, and Non-goals_.
|
||||||
|
|
||||||
|
* A deployer can specify the new ``idrac-redfish`` and ``idrac-wsman``
|
||||||
|
interface 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.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
rpioso
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
None
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Define two new groups of interface implementations with entrypoints named
|
||||||
|
``idrac-redfish`` and ``idrac-wsman``.
|
||||||
|
|
||||||
|
* Declare ``idrac`` hardware type support for the ``idrac``, ``idrac-redfish``,
|
||||||
|
and ``idrac-wsman`` interface implementations.
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
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 ``idrac``
|
||||||
|
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-redfish`` and
|
||||||
|
``idrac-wsman`` interface implementation entrypoints as soon as it is possible.
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
The `iDRAC driver`_ documentation is updated to:
|
||||||
|
|
||||||
|
* describe switching from the legacy ``idrac`` interface implementation
|
||||||
|
entrypoints to the new ``idrac-redfish`` and ``idrac-wsman`` entrypoints,
|
||||||
|
|
||||||
|
* reflect the changes to the supported interface implementations, and
|
||||||
|
|
||||||
|
* inform that a node configuration with a mix of Redfish and WS-Man
|
||||||
|
``management`` and ``power`` interface implementations is not supported.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
OpenStack software projects:
|
||||||
|
- `ironic`_
|
||||||
|
- `python-dracclient`_
|
||||||
|
- `sushy`_
|
||||||
|
|
||||||
|
Related Ironic specifications:
|
||||||
|
- `Driver composition reform`_
|
||||||
|
|
||||||
|
Documentation:
|
||||||
|
- `iDRAC driver`_
|
||||||
|
- `Redfish driver`_
|
||||||
|
- `TripleO register nodes`_
|
||||||
|
|
||||||
|
Standards:
|
||||||
|
- IPMI_
|
||||||
|
- Redfish_
|
||||||
|
- WS-Man_
|
||||||
|
|
||||||
|
.. rubric:: Footnotes
|
||||||
|
|
||||||
|
.. [#f1] See the *introduction* paragraph of the Ironic
|
||||||
|
`Driver composition reform`_.
|
||||||
|
.. [#f2] See the *Introduction* subsection in the *Proposed change* section of
|
||||||
|
the Ironic `Driver composition reform`_.
|
||||||
|
|
||||||
|
.. _Driver composition reform: https://specs.openstack.org/openstack/ironic-specs/specs/7.0/driver-composition-reform.html
|
||||||
|
.. _iDRAC driver: https://docs.openstack.org/ironic/latest/admin/drivers/idrac.html
|
||||||
|
.. _IPMI: https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-technical-resources.html
|
||||||
|
.. _ironic: https://opendev.org/openstack/ironic.git
|
||||||
|
.. _python-dracclient: https://opendev.org/openstack/python-dracclient.git
|
||||||
|
.. _Redfish: https://www.dmtf.org/standards/redfish
|
||||||
|
.. _Redfish driver: https://docs.openstack.org/ironic/latest/admin/drivers/redfish.html
|
||||||
|
.. _sushy: https://opendev.org/openstack/sushy.git
|
||||||
|
.. _TripleO register nodes: https://docs.openstack.org/tripleo-docs/latest/install/basic_deployment/basic_deployment_cli.html#register-nodes
|
||||||
|
.. _WS-Man: https://www.dmtf.org/standards/ws-man
|
|
@ -0,0 +1 @@
|
||||||
|
../approved/idrac-support-of-redfish-interfaces.rst
|
Loading…
Reference in New Issue