Release notes cleanup for 13.0.0
Change-Id: I0a2c5345b7f72014528a73ece68f442745f64302
This commit is contained in:
Dmitry Tantsur
parent
2dce6bde1b
commit
68e6daf717
@ -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.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
fixes:
|
||||
- |
|
||||
Allows deleting unbound ports on an active node. See
|
||||
https://storyboard.openstack.org/#!/story/2006385 for details.
|
||||
Allows deleting unbound ports on an active node. See `story 2006385
|
||||
<https://storyboard.openstack.org/#!/story/2006385>`_ for details.
|
||||
|
||||
@ -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
|
||||
``nova.send_power_notifications`` config option. Whenever there is a change
|
||||
in the power state of a physical instance (for example a "power on" or
|
||||
"power off" API command is issued or during the periodic power state
|
||||
synchronization between nova and ironic) the Baremetal service will create
|
||||
and send a ``power-update`` external event to the Compute service which will
|
||||
cause the power state of the instance to be updated in its database. It
|
||||
also adds the possibility of bringing up/down a physical instance through
|
||||
the Baremetal service API even if it was put down/up through the Compute
|
||||
service API.
|
||||
performing API notifications. This feature is enabled by default and can be
|
||||
disabled via the new ``[nova]send_power_notifications`` configuration
|
||||
option.
|
||||
|
||||
Whenever there is a change in the power state of a physical instance,
|
||||
the Bare Metal service will send a ``power-update`` external event to
|
||||
the Compute service which will cause the power state of the instance
|
||||
to be updated in the Compute database. It also adds the possibility of
|
||||
bringing up/down a physical instance through the Bare Metal 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
|
||||
Baremetal service only sends requests to the Compute service if the target
|
||||
power state is either "power on" or "power off") of an instance through
|
||||
external events to the Compute service, the Baremetal service becomes the
|
||||
source of truth thus preventing the Compute service from forcing wrong
|
||||
power states on the instance during the periodic power state
|
||||
synchronization between nova and ironic. An exception would be if a race
|
||||
condition were to occur due to the nova-ironic power sync task happening
|
||||
a nano-second before the power state change event is received from the
|
||||
Baremetal service in which case the nova instance state will be forced
|
||||
on the baremetal node.
|
||||
By immediately conveying power state changes of a node through
|
||||
external events to the Compute service, the Bare Metal service becomes the
|
||||
source of truth about the node's power state, preventing the Compute
|
||||
service from forcing wrong power states on instances during the periodic
|
||||
power state synchronization between the Compute and Bare Metal services.
|
||||
|
||||
.. note::
|
||||
There is a possibility of a race condition due to the nova-ironic power
|
||||
sync task happening during or right before the power state change
|
||||
event is received from the Bare Metal service, in which case the
|
||||
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.
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
---
|
||||
fixes:
|
||||
- |
|
||||
An issue regarding the ``ansible`` deploy interface. The discovery
|
||||
playbook used to gather wwn and serials was broken for python3 due to the
|
||||
dict().keys() object not being a list in python3.
|
||||
Fixes an issue in the discovery playbook for the ``ansible`` deploy
|
||||
interface that prevented gathering WWN and serial numbers under Python 3.
|
||||
|
||||
@ -1,7 +1,4 @@
|
||||
---
|
||||
fixes:
|
||||
- |
|
||||
Fixes an issue regarding the ``ansible`` deploy interface. Node
|
||||
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.
|
||||
- |
|
||||
Fixes deploying non-public images using the ``ansible`` deploy interface.
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
---
|
||||
features:
|
||||
- |
|
||||
Adds a new configuration option ``boot_device_job_status_timeout`` that
|
||||
specifies the Maximum amount of time (in seconds) to wait for the boot
|
||||
Adds a new configuration option ``[drac]boot_device_job_status_timeout``
|
||||
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
|
||||
correct state and start execution during a power on or reboot operation. If
|
||||
the boot device is being changed, the system might complete its POST before
|
||||
the job is ready, leaving the job in the queue, and the system will boot
|
||||
from the wrong device.
|
||||
Fixes an issue in the ``idrac`` hardware type where a configuration job
|
||||
does not transition to the correct state and start execution during
|
||||
a power on or reboot operation. If the boot device is being changed,
|
||||
the system might complete its POST before the job is ready, leaving
|
||||
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.
|
||||
|
||||
@ -1,9 +1,10 @@
|
||||
---
|
||||
features:
|
||||
- |
|
||||
Adds support for the Intel IPMI Hardware with hardware type
|
||||
``intel-ipmitool``. This hardware type is same as ``ipmi`` hardware 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>`.
|
||||
It uses management interface ``intel-ipmitool``. It supports setting
|
||||
Adds support for the Intel IPMI Hardware with a new hardware type
|
||||
``intel-ipmitool``. This hardware type is the same as the ``ipmi`` hardware
|
||||
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>`_.
|
||||
It uses the ``intel-ipmitool`` management interface, which supports setting
|
||||
the desired configuration level for Intel SST-PP.
|
||||
|
||||
@ -1,17 +1,10 @@
|
||||
---
|
||||
upgrade:
|
||||
- |
|
||||
iRMC hardware type deals with iPXE boot interface incompatibility.
|
||||
To iPXE boot with ``ipxe`` boot interface, *(1)* add ``ipxe`` to
|
||||
``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``.
|
||||
Users of the ``irmc`` hardware type with iPXE should switch to the ``ipxe``
|
||||
boot interface from the deprecated ``[pxe]ipxe_enabled`` option.
|
||||
fixes:
|
||||
- |
|
||||
iRMC hardware type deals with iPXE boot interface incompatibility.
|
||||
From Stein, ``[pxe]ipxe_enabled`` option has been deprecated and will be
|
||||
removed in preference to ``ipxe`` boot interface in Train cycle. Till then,
|
||||
iRMC hardware type supports iPXE boot through ``[pxe]ipxe_enabled`` option.
|
||||
To cope with this incompatibility, iRMC hardware type supports ``ipxe``
|
||||
boot interface.
|
||||
Adds the missing ``ipxe`` boot interface to the ``irmc`` hardware type.
|
||||
It is supposed to be used instead of the deprecated ``[pxe]ipxe_enabled``
|
||||
configuration option.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
upgrade:
|
||||
- remove deprecated ``ironic/api/app.wsgi`` script.
|
||||
The automatically generated ``ironic-api-wsgi`` script should be used
|
||||
- The deprecated ``ironic/api/app.wsgi`` script has been removed.
|
||||
The automatically generated ``ironic-api-wsgi`` script must be used
|
||||
instead.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user