Előd Illés 43f5e8ca16 nova: Release Xena 24.2.1
$ git log --oneline --no-merges 24.2.0..706ee6010a
c3800f7863 Handle mdev devices in libvirt 7.7+
fdd4e7dc51 Reproducer for bug 1951656
30c7180e1e Add debug log for scheduler weight calculation
5b1d487d7f db: Resolve additional SAWarning warnings
e099571d0f Improving logging at '_allocate_mdevs'.
997d3a4ddb nova-live-migration tests not needed for Ironic
1aa9e0de6f Accept both 1 and Y as AMD SEV KVM kernel param value

Change-Id: Id53daa92af865785818342e204bd89e4b490bfb0
2023-04-11 18:51:26 +02:00

64 lines
2.6 KiB
YAML

---
launchpad: nova
release-model: cycle-with-rc
team: nova
type: service
repository-settings:
openstack/nova: {}
cycle-highlights:
- |
Nova now supports `Cyborg managed SmartNICs
<https://docs.openstack.org/api-guide/compute/accelerator-support.html#using-sriov-with-cyborg>`_
represented by Neutron ports and attached as SRIOV devices to the Nova servers.
- |
Nova's libvirt virt driver now supports any PCI devices, not just virtual GPUs, that are using
the ``VFIO-mdev`` virtualization framework like network adapters or compute accelerators.
`See more in the spec <https://specs.openstack.org/openstack/nova-specs/specs/xena/approved/generic-mdevs.html>`_
- |
Nova stores the cinder volume connection_info in its database. Over time this information can
become stale if changes are made in the environment, the most common example of which being the
changing of MON IP addresses when using Ceph as the backing store for the Cinder volume service.
Previously operators have had to query the database directly for an understanding of the current
state of the connection_info and could only migrate or shelve the instance to force a refresh
of this. Now Nova provides a set of ``nova-manage``
`CLI commands <https://docs.openstack.org/nova/latest/cli/nova-manage.html#volume-attachment-commands>`_
to read and refresh the stale information.
- |
`API microversion 2.90 <https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-xena>`_
allows users to configure the hostname that will be exposed via the nova metadata service when
creating or rebuilding their instance.
releases:
- version: 24.0.0.0rc1
projects:
- repo: openstack/nova
hash: 1c502ebaec29615f08d4af7dc6680f3141d70e67
- version: 24.0.0.0rc2
projects:
- repo: openstack/nova
hash: 928d3feffd674a842d4bb4348d2f0e0d7e93a8a5
- version: 24.0.0
projects:
- repo: openstack/nova
hash: 928d3feffd674a842d4bb4348d2f0e0d7e93a8a5
diff-start: 23.0.0.0rc1
- version: 24.1.0
projects:
- repo: openstack/nova
hash: 6f81db2dd65060135ac093aa3b1c8bd08ac0af0c
- version: 24.1.1
projects:
- repo: openstack/nova
hash: 3872647092353229302919d305758f3fc777277f
- version: 24.2.0
projects:
- repo: openstack/nova
hash: ac3728e1239fe2aeffc2a06bbeab6a24eff28ae9
- version: 24.2.1
projects:
- repo: openstack/nova
hash: 706ee6010a3720b9d9faf72d6782665b6eb083a7
branches:
- name: stable/xena
location: 24.0.0.0rc1
release-notes: https://docs.openstack.org/releasenotes/nova/xena.html