diff options
Diffstat (limited to 'releasenotes')
8 files changed, 131 insertions, 0 deletions
diff --git a/releasenotes/notes/allowing-target-state-for-evacuate-d4c1912c481973d6.yaml b/releasenotes/notes/allowing-target-state-for-evacuate-d4c1912c481973d6.yaml new file mode 100644 index 0000000000..6c5bc98046 --- /dev/null +++ b/releasenotes/notes/allowing-target-state-for-evacuate-d4c1912c481973d6.yaml @@ -0,0 +1,13 @@ +--- +features: + - | + Starting with v2.95 any evacuated instance will be stopped at + destination. The required minimum version for Nova computes is + 27.0.0 (antelope 2023.1). Operator can still continue using + previous behavior by selecting microversion below v2.95. +upgrade: + - | + Operators will have to consider upgrading compute hosts to Nova + 27.0.0 (antelope 2023.1) in order to take advantage of the new + (microversion v2.95) evacuate API behavior. An exception will be + raised for older versions. diff --git a/releasenotes/notes/bp-pci-device-tracking-in-placement-antelope-082310a2b0337e0e.yaml b/releasenotes/notes/bp-pci-device-tracking-in-placement-antelope-082310a2b0337e0e.yaml new file mode 100644 index 0000000000..7a9e53ed26 --- /dev/null +++ b/releasenotes/notes/bp-pci-device-tracking-in-placement-antelope-082310a2b0337e0e.yaml @@ -0,0 +1,8 @@ +--- +features: + - | + Since 26.0.0 (Zed) Nova supports tracking PCI devices in Placement. Now + Nova also supports scheduling flavor based PCI device requests via + Placement. This support is disable by default. Please read + `documentation <https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#pci-tracking-in-placement>`_ + for more details on what is supported how this feature can be enabled. diff --git a/releasenotes/notes/bug-1996995-qemu_monitor_announce_self-add-configurables-2b2f19d238442f72.yaml b/releasenotes/notes/bug-1996995-qemu_monitor_announce_self-add-configurables-2b2f19d238442f72.yaml new file mode 100644 index 0000000000..0941dd7450 --- /dev/null +++ b/releasenotes/notes/bug-1996995-qemu_monitor_announce_self-add-configurables-2b2f19d238442f72.yaml @@ -0,0 +1,28 @@ +--- +fixes: + - | + Fixes `bug 1996995`_ in which VMs live migrated on certain VXLAN Arista + network fabrics were inaccessible until the switch arp cache expired. + + A Nova workaround option of ``enable_qemu_monitor_announce_self`` was added + to fix `bug 1815989`_ which when enabled would interact with the QEMU + monitor and force a VM to announce itself. + + On certain network fabrics, VMs that are live migrated remain inaccessible + via the network despite the QEMU monitor announce_self command successfully + being called. + + It was noted that on Arista VXLAN fabrics, testing showed that it required + several attempts of running the QEMU announce_self monitor command before + the switch would acknowledge a VM's new location on the fabric. + + This fix introduces two operator configurable options. + The first option sets the number of times the QEMU monitor announce_self + command is called - ``qemu_announce_self_count`` + + The second option allows operators to set the delay between the QEMU + announce_self commands in seconds for subsequent announce_self commands + with ``qemu_announce_self_interval`` + + .. _`bug 1996995`: https://bugs.launchpad.net/nova/+bug/1996995 + .. _`bug 1815989`: https://bugs.launchpad.net/nova/+bug/1815989 diff --git a/releasenotes/notes/enable-enforce-scope-and-new-defaults-14db8c75b263b599.yaml b/releasenotes/notes/enable-enforce-scope-and-new-defaults-14db8c75b263b599.yaml new file mode 100644 index 0000000000..72a6f861b6 --- /dev/null +++ b/releasenotes/notes/enable-enforce-scope-and-new-defaults-14db8c75b263b599.yaml @@ -0,0 +1,23 @@ +--- +upgrade: + - | + The Nova service enable the API policies (RBAC) new defaults and scope by + default. The Default value of config options ``[oslo_policy] enforce_scope`` + and ``[oslo_policy] oslo_policy.enforce_new_defaults`` have been changed + to ``True``. + + This means if you are using system scope token to access Nova API then + the request will be failed with 403 error code. Also, new defaults will be + enforced by default. To know about the new defaults of each policy + rule, refer to the `Policy New Defaults`_. For more detail about the Nova + API policies changes, refer to `Policy Concepts`_. + + If you want to disable them then modify the below config options value in + ``nova.conf`` file:: + + [oslo_policy] + enforce_new_defaults=False + enforce_scope=False + + .. _`Policy New Defaults`: https://docs.openstack.org/nova/latest/configuration/policy.html + .. _`Policy Concepts`: https://docs.openstack.org/nova/latest/configuration/policy-concepts.html diff --git a/releasenotes/notes/microversion-2-94-59649401d5763286.yaml b/releasenotes/notes/microversion-2-94-59649401d5763286.yaml new file mode 100644 index 0000000000..d0927e6f75 --- /dev/null +++ b/releasenotes/notes/microversion-2-94-59649401d5763286.yaml @@ -0,0 +1,22 @@ +--- +features: + - | + The 2.94 microversion has been added. This microversion extends + microversion 2.90 by allowing Fully Qualified Domain Names (FQDN) wherever + the ``hostname`` is able to be specified. This consists of creating an + instance (``POST /servers``), updating an instance + (``PUT /servers/{id}``), or rebuilding an instance + (``POST /servers/{server_id}/action (rebuild)``). When using an FQDN as the + instance hostname, the ``[api]dhcp_domain`` configuration option must be + set to the empty string in order for the correct FQDN to appear in the + ``hostname`` field in the metadata API. + +upgrade: + - | + In order to make use of microversion's 2.94 FQDN hostnames, the + ``[api]dhcp_domain`` config option must be set to the empty string. If + this is not done, the ``hostname`` field in the metadata API will be + incorrect, as it will include the value of ``[api]dhcp_domain`` appended to + the instance's FQDN. Note that simply not setting ``[api]dhcp_domain`` is + not enough, as it has a default value of ``novalocal``. It must explicitly + be set to the empty string. diff --git a/releasenotes/notes/rescue-volume-based-instance-c6e3fba236d90be7.yaml b/releasenotes/notes/rescue-volume-based-instance-c6e3fba236d90be7.yaml new file mode 100644 index 0000000000..7e80059b80 --- /dev/null +++ b/releasenotes/notes/rescue-volume-based-instance-c6e3fba236d90be7.yaml @@ -0,0 +1,6 @@ +--- +fixes: + - | + Fix rescuing volume based instance by adding a check for 'hw_rescue_disk' + and 'hw_rescue_device' properties in image metadata before attempting + to rescue instance. diff --git a/releasenotes/notes/stable-compute-uuid-08663a0955616728.yaml b/releasenotes/notes/stable-compute-uuid-08663a0955616728.yaml new file mode 100644 index 0000000000..fdeb593bd2 --- /dev/null +++ b/releasenotes/notes/stable-compute-uuid-08663a0955616728.yaml @@ -0,0 +1,19 @@ +--- +features: + - | + The compute manager now uses a local file to provide node uuid persistence + to guard against problems with renamed services, among other things. + Deployers wishing to ensure that *new* compute services get a predicatble + uuid before initial startup may provision that file and nova will use it, + otherwise nova will generate and write one to a `compute_id` file in + `CONF.state_path` the first time it starts up. Accidental renames of a + compute node's hostname will be detected and the manager will exit to avoid + database corruption. Note that none of this applies to Ironic computes, as + they manage nodes and uuids differently. +upgrade: + - | + Existing compute nodes will, upon upgrade, perist the uuid of the compute + node assigned to their hostname at first startup. Since this must match + what is currently in the database, it is important to let nova provision + this file from its database. Nova will only persist to a `compute_id` file + in the `CONF.state_path` directory, which should already be writable. diff --git a/releasenotes/notes/use-compareHypervisorCPU-b75c8f097cc73556.yaml b/releasenotes/notes/use-compareHypervisorCPU-b75c8f097cc73556.yaml new file mode 100644 index 0000000000..924e09a602 --- /dev/null +++ b/releasenotes/notes/use-compareHypervisorCPU-b75c8f097cc73556.yaml @@ -0,0 +1,12 @@ +--- +fixes: + - | + Nova's use of libvirt's compareCPU() API has become error-prone as + it doesn't take into account host hypervisor's capabilities. With + QEMU >=2.9 and libvirt >= 4.4.0, libvirt will do the right thing in + terms of CPU comparison checks via a new replacement API, + compareHypervisorCPU(). Nova satisfies the said minimum version + requirements of QEMU and libvirt by a good margin. + + This change replaces the usage of older API, compareCPU(), with the + new one, compareHypervisorCPU(). |