Release notes cleanup for 13.0.0

Change-Id: I0a2c5345b7f72014528a73ece68f442745f64302

releasenotes/notes/adds-ilo-ipxe-boot-interface-4fc75292122db80d.yaml

@@ -11,9 +11,3 @@ features:
       configuration
       <https://docs.openstack.org/ironic/latest/install/configure-pxe.html>`_
     * Create/Set baremetal node with ``--boot-interface ilo-ipxe``
-fixes:
-  - |
-    From Stein release, ``[pxe]ipxe_enabled`` option has been deprecated.
-    The ``ilo`` hardware type supports iPXE boot through
-    ``[pxe]ipxe_enabled`` option. To cope with this incompatibility,
-    ``ilo`` hardware type has added new ``ilo-ipxe`` boot interface.

releasenotes/notes/allow-deleting-unbound-ports-fa78069b52f099ac.yaml

@@ -1,5 +1,5 @@
 ---
 fixes:
   - |
-    Allows deleting unbound ports on an active node. See
+    Allows deleting unbound ports on an active node. See `story 2006385
-    https://storyboard.openstack.org/#!/story/2006385 for details.
+    <https://storyboard.openstack.org/#!/story/2006385>`_ for details.

releasenotes/notes/bp-nova-support-instance-power-update-49c531ef13982e62.yaml

@@ -2,33 +2,33 @@
 features:
   - |
     Adds power state change callbacks of an instance to the Compute service by
-    performing API notifications. This is configurable through the
+    performing API notifications. This feature is enabled by default and can be
-    ``nova.send_power_notifications`` config option. Whenever there is a change
+    disabled via the new ``[nova]send_power_notifications`` configuration
-    in the power state of a physical instance (for example a "power on" or
+    option.
-    "power off" API command is issued or during the periodic power state
+
-    synchronization between nova and ironic) the Baremetal service will create
+    Whenever there is a change in the power state of a physical instance,
-    and send a ``power-update`` external event to the Compute service which will
+    the Bare Metal service will send a ``power-update`` external event to
-    cause the power state of the instance to be updated in its database. It
+    the Compute service which will cause the power state of the instance
-    also adds the possibility of bringing up/down a physical instance through
+    to be updated in the Compute database. It also adds the possibility of
-    the Baremetal service API even if it was put down/up through the Compute
+    bringing up/down a physical instance through the Bare Metal service API
-    service API.
+    even if it was put down/up through the Compute service API.
 fixes:
   - |
-    By immediately conveying all the power state changes (note that the
+    By immediately conveying power state changes of a node through
-    Baremetal service only sends requests to the Compute service if the target
+    external events to the Compute service, the Bare Metal service becomes the
-    power state is either "power on" or "power off") of an instance through
+    source of truth about the node's power state, preventing the Compute
-    external events to the Compute service, the Baremetal service becomes the
+    service from forcing wrong power states on instances during the periodic
-    source of truth thus preventing the Compute service from forcing wrong
+    power state synchronization between the Compute and Bare Metal services.
-    power states on the instance during the periodic power state
+
-    synchronization between nova and ironic. An exception would be if a race
+    .. note::
-    condition were to occur due to the nova-ironic power sync task happening
+        There is a possibility of a race condition due to the nova-ironic power
-    a nano-second before the power state change event is received from the
+        sync task happening during or right before the power state change
-    Baremetal service in which case the nova instance state will be forced
+        event is received from the Bare Metal service, in which case the
-    on the baremetal node.
+        instance state will be forced on the baremetal node.
 upgrade:
   - |
     In order to support power state change call backs to nova, the ``[nova]``
-    section must be configured in the baremetal service configuration.
+    section must be configured in the Bare Metal service configuration.
     As the functionality to process the event is new to nova's Train release,
     this should only be set to ``True`` in ironic, once *ALL* ``nova-compute``
     instances have been upgraded to the Train release of nova.

releasenotes/notes/bug-2006266-85da234583ca0c32.yaml

@@ -1,6 +1,5 @@
 ---
 fixes:
   - |
-      An issue regarding the ``ansible`` deploy interface. The discovery
+    Fixes an issue in the discovery playbook for the ``ansible`` deploy
-      playbook used to gather wwn and serials was broken for python3 due to the
+    interface that prevented gathering WWN and serial numbers under Python 3.
-      dict().keys() object not being a list in python3.

releasenotes/notes/bug-35702-25da234580ca0c31.yaml

@@ -1,7 +1,4 @@
 ---
 fixes:
-      - |
+  - |
-          Fixes an issue regarding the ``ansible`` deploy interface. Node
+    Fixes deploying non-public images using the ``ansible`` deploy interface.
-          deployment was broken for any image that was not public because
-          the original request context was not available anymore at the time
-          some image information was fetched.

releasenotes/notes/drac-fix-power-on-reboot-race-condition-fe712aa9c79ee252.yaml

@@ -1,16 +1,16 @@
 ---
 features:
   - |
-    Adds a new configuration option ``boot_device_job_status_timeout`` that
+    Adds a new configuration option ``[drac]boot_device_job_status_timeout``
-    specifies the Maximum amount of time (in seconds) to wait for the boot
+    that specifies the maximum amount of time (in seconds) to wait for the boot
     device configuration job to transition to the scheduled state to allow a
     reboot or power on action to complete.
 fixes:
   - |
-    Fixes an issue where a configuration job does not transition to the
+    Fixes an issue in the ``idrac`` hardware type where a configuration job
-    correct state and start execution during a power on or reboot operation. If
+    does not transition to the correct state and start execution during
-    the boot device is being changed, the system might complete its POST before
+    a power on or reboot operation. If the boot device is being changed,
-    the job is ready, leaving the job in the queue, and the system will boot
+    the system might complete its POST before the job is ready, leaving
-    from the wrong device.
+    the job in the queue, and the system will boot from the wrong device.
     See bug `2004909 <https://storyboard.openstack.org/#!/story/2004909>`_ for
-    details.
+    details.

releasenotes/notes/intel-ipmi-hardware-30aaa65cdbcb779a.yaml

@@ -1,9 +1,10 @@
 ---
 features:
   - |
-    Adds support for the Intel IPMI Hardware with hardware type
+    Adds support for the Intel IPMI Hardware with a new hardware type
-    ``intel-ipmitool``. This hardware type is same as ``ipmi`` hardware type
+    ``intel-ipmitool``. This hardware type is the same as the ``ipmi`` hardware
-    with additional support of `Intel Speed Select Performance Profile
+    type with additional support of `Intel Speed Select Performance Profile
-    Technology <https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html>`.
+    Technology
-    It uses management interface ``intel-ipmitool``. It supports setting
+    <https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html>`_.
+    It uses the ``intel-ipmitool`` management interface, which supports setting
     the desired configuration level for Intel SST-PP.

releasenotes/notes/irmc-dealing-with-ipxe-boot-interface-incompatibility-7d0b2bdb8f9deb46.yaml

@@ -1,17 +1,10 @@
 ---
 upgrade:
   - |
-    iRMC hardware type deals with iPXE boot interface incompatibility.
+    Users of the ``irmc`` hardware type with iPXE should switch to the ``ipxe``
-    To iPXE boot with ``ipxe`` boot interface, *(1)* add ``ipxe`` to
+    boot interface from the deprecated ``[pxe]ipxe_enabled`` option.
-    ``enabled_boot_interfaces`` in ``ironic.conf``, *(2)* set up tftp &
-    http server following `Ironic document on iPXE boot configuration
-    <https://docs.openstack.org/ironic/latest/install/configure-pxe.html>`,
-    then *(3)* create/set baremetal node with ``--boot-interface ipxe``.
 fixes:
   - |
-    iRMC hardware type deals with iPXE boot interface incompatibility.
+    Adds the missing ``ipxe`` boot interface to the ``irmc`` hardware type.
-    From Stein, ``[pxe]ipxe_enabled`` option has been deprecated and will be
+    It is supposed to be used instead of the deprecated ``[pxe]ipxe_enabled``
-    removed in preference to ``ipxe`` boot interface in Train cycle. Till then,
+    configuration option.
-    iRMC hardware type supports iPXE boot through ``[pxe]ipxe_enabled`` option.
-    To cope with this incompatibility, iRMC hardware type supports ``ipxe``
-    boot interface.

releasenotes/notes/remove-app-wsgi-d5887ca28e4b9f00.yaml

@@ -1,5 +1,5 @@
 ---
 upgrade:
-  - remove deprecated ``ironic/api/app.wsgi`` script.
+  - The deprecated ``ironic/api/app.wsgi`` script has been removed.
-    The automatically generated ``ironic-api-wsgi`` script should be used
+    The automatically generated ``ironic-api-wsgi`` script must be used
     instead.