Merge "Update the doc regarding the removal of calssic drivers"

This commit is contained in:
Zuul 2018-07-14 19:51:32 +00:00 committed by Gerrit Code Review
commit 036d6247e5
5 changed files with 20 additions and 58 deletions

View File

@ -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
--------------------

View File

@ -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
-----------------------

View File

@ -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/

View File

@ -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`_.

View File

@ -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;