openstack/ironic
Code Issues Proposed changes

Update the doc regarding the removal of calssic drivers

Browse Source 
This patch updates the remaining doc that relates to
the removal of classic drivers.

Change-Id: I82b1ee18ea90bfdf8ab9b24e610fb5db766068a0
This commit is contained in:
Dao Cong Tien 2018-07-09 16:13:54 +07:00
parent 60977594d2
commit a60233ccf4
5 changed files with 20 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
doc/source/admin/upgrade-to-hardware-types.rst
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
--------------------

4
doc/source/contributor/drivers.rst
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
-----------------------

32
doc/source/install/enabling-drivers.rst
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/

27
doc/source/install/enrollment.rst
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`_.

6
doc/source/user/index.rst
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;