diff --git a/doc/source/admin/upgrade-to-hardware-types.rst b/doc/source/admin/upgrade-to-hardware-types.rst
index 8fd87c99e1..7daaada0a5 100644
--- a/doc/source/admin/upgrade-to-hardware-types.rst
+++ b/doc/source/admin/upgrade-to-hardware-types.rst
@@ -1,10 +1,11 @@
Upgrading to Hardware Types
===========================
-In the future, the Bare Metal service will stop supporting *classic drivers*
-and will only support *hardware types*. Please see
-:doc:`/install/enabling-drivers` for the detailed explanation of the
-difference between these two types of drivers.
+Starting with the Rocky release, the Bare Metal service does not support
+*classic drivers* any more. If you still use *classic drivers*, please
+upgrade to *hardware types* immediately. Please see
+:doc:`/install/enabling-drivers` for details on
+*hardware types* and *hardware interfaces*.
Planning the upgrade
--------------------
diff --git a/doc/source/contributor/drivers.rst b/doc/source/contributor/drivers.rst
index 559c9cf1e4..519a58a7b2 100644
--- a/doc/source/contributor/drivers.rst
+++ b/doc/source/contributor/drivers.rst
@@ -29,10 +29,6 @@ the following command against that API end point::
openstack baremetal driver list
-.. note::
- This listing also includes *classic drivers* which are deprecated and
- are not covered by this guide.
-
Writing a hardware type
-----------------------
diff --git a/doc/source/install/enabling-drivers.rst b/doc/source/install/enabling-drivers.rst
index 5703469f0d..1f5ab2d90e 100644
--- a/doc/source/install/enabling-drivers.rst
+++ b/doc/source/install/enabling-drivers.rst
@@ -5,24 +5,16 @@ Introduction
------------
The Bare Metal service delegates actual hardware management to **drivers**.
-Starting with the Ocata release, two types of drivers are supported:
-*classic drivers* and the newer *hardware types* (for example, generic
-``redfish`` and ``ipmi`` or vendor-specific ``ilo`` and ``irmc``).
+*Drivers*, also called *hardware types*, consist of *hardware interfaces*:
+sets of functionality dealing with some aspect of bare metal provisioning
+in a vendor-specific way. There are generic **hardware types** (eg.
+``redfish`` and ``ipmi``), and vendor-specific ones (eg. ``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*.
-
-.. TODO(dtantsur): write devdocs on the driver composition and stop linking
- to the specification.
-
-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.
+.. note::
+ Starting with the Rocky release, the terminologies *driver*,
+ *dynamic driver*, and *hardware type* have the same meaning
+ in the scope of Bare Metal service.
.. _enable-hardware-types:
@@ -130,9 +122,8 @@ management
Using ``ipmitool`` requires :doc:`configure-ipmi`. See
:doc:`/admin/drivers` for the 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
- :doc:`configure-tenant-networks` for more details.
+ connects/disconnects bare metal nodes to/from virtual networks.
+ See :doc:`configure-tenant-networks` for 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
@@ -300,6 +291,5 @@ existing nodes.
support the provided default implementation, its users will have to always
provide an explicit value for this interface when creating a node.
-.. _driver composition reform specification: https://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html
.. _setup.cfg: https://git.openstack.org/cgit/openstack/ironic/tree/setup.cfg
.. _ironic-inspector: https://docs.openstack.org/ironic-inspector/latest/
diff --git a/doc/source/install/enrollment.rst b/doc/source/install/enrollment.rst
index eaad71402a..368488e164 100644
--- a/doc/source/install/enrollment.rst
+++ b/doc/source/install/enrollment.rst
@@ -30,9 +30,7 @@ Choosing a driver
When enrolling a node, the most important information to supply is *driver*.
See :doc:`enabling-drivers` for a detailed explanation of bare metal drivers,
-hardware types and interfaces. Starting with the Pike release, we recommend
-the use of *hardware types* instead of *classic drivers*, since classic drivers
-may be deprecated in the near future. The ``driver list`` command can be used
+hardware types and interfaces. The ``driver list`` command can be used
to list all drivers enabled on all hosts:
.. code-block:: console
@@ -44,19 +42,6 @@ to list all drivers enabled on all hosts:
| ipmi | localhost.localdomain |
+---------------------+-----------------------+
-Starting with API version 1.31 (and ``python-ironicclient`` 1.13), you can
-also list only classic drivers or only hardware types via the ``--type``
-argument:
-
-.. code-block:: console
-
- openstack baremetal --os-baremetal-api-version 1.31 driver list --type dynamic
- +---------------------+-----------------------+
- | Supported driver(s) | Active host(s) |
- +---------------------+-----------------------+
- | ipmi | localhost.localdomain |
- +---------------------+-----------------------+
-
The specific driver to use should be picked based on actual hardware
capabilities and expected features. See :doc:`/admin/drivers` for more hints
on that.
@@ -179,9 +164,7 @@ and may be combined if desired.
pick which hardware interface to use with nodes that use hardware types.
Each interface is represented by a node field called ``<IFACE>_interface``
where ``<IFACE>`` in the interface type, e.g. ``boot``. See
- :doc:`enabling-drivers` for details on hardware interfaces and
- :doc:`/admin/upgrade-to-hardware-types` for the matching between classic
- drivers and hardware types.
+ :doc:`enabling-drivers` for details on hardware interfaces.
An interface can be set either separately:
@@ -202,10 +185,6 @@ and may be combined if desired.
If no value is provided for some interfaces, `Defaults for hardware
interfaces`_ are used instead.
- It's an error to try changing this field for a node with a *classic driver*,
- and setting node's driver to classic one causes these fields to be set
- to ``None`` automatically.
-
#. Update the node ``driver_info`` with the required driver properties, so that
the Bare Metal service can manage the node:
@@ -575,8 +554,6 @@ UUID interchangeably:
Defaults for hardware interfaces
--------------------------------
-For *classic drivers* all hardware interface implementations (except for the
-*network interface*) are hardcoded and cannot be changed.
For *hardware types*, users can request one of enabled implementations when
creating or updating a node as explained in `Creating a node`_.
diff --git a/doc/source/user/index.rst b/doc/source/user/index.rst
index 9004672402..3d1b1a46ce 100644
--- a/doc/source/user/index.rst
+++ b/doc/source/user/index.rst
@@ -179,8 +179,8 @@ the same.
boot of a node.
#. The ironic node's deploy interface caches the instance image (in case of
- ``iscsi`` deploy interface or most ``pxe_*`` classic drivers), and kernel
- and ramdisk if needed (it is needed in case of netboot for example).
+ ``iscsi`` deploy interface), and kernel and ramdisk if needed (it is
+ needed in case of netboot for example).
#. The ironic node's power interface instructs the node to power on.
@@ -268,7 +268,6 @@ This process is how :ref:`iscsi-deploy` works.
.. seqdiag::
:scale: 75
- :alt: pxe_ipmi
diagram {
Nova; API; Conductor; Neutron; HTTPStore; "TFTP/HTTPd"; Node;
@@ -327,7 +326,6 @@ This process is how :ref:`direct-deploy` works.
.. seqdiag::
:scale: 75
- :alt: pxe_ipmi_agent
diagram {
Nova; API; Conductor; Neutron; HTTPStore; "TFTP/HTTPd"; Node;