As per 2025.1 testing runtime[1], we need to test on Ubuntu
Noble (which will be taken care by tempest and devstack
patches to move base jobs to Noble (depends-On)) and at least single
job to run on Ubutnu Jammy (for smooth upgrade from previous
releases).
This commit keep rbac old default job continue running on Jammy
which can be moved to noble in next cycle.
Depends-On: https://review.opendev.org/c/openstack/tempest/+/932156
[1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html
Change-Id: I99c0eb76d63a5902555f5527dbfdaf96c47a098f
If a compute is started up while an evacuation of an instance from this
host is still in progress then the destroy_evacuated_instances call will
try to check if the instance is on shared storage to decide if the local
disk needs to deleted from the source node or not. However this call
uses the instance.host to target the RPC call. If the evacuation is
still ongoing then the instance.host might still be set to the source
node. This means the source node during init_host tries to call RPC
on itself. This will always time out as the RPC server is only started
after init_host. Also it is wrong as the shared storage check RPC
should be called on another host. Moreover when this wrongly routed RPC
times out the source compute logs the exception, ignores it, and the
assume the disk is on shared storage so won't clean it up. This means
that a later evacuation of this VM targeting this node will fails as the
instance directory is already present on the node.
The fix is simple, the destroy_evacuated_instances call should always
send the shared storage check RPC call to the destination node of the
evacuation based on the migration record. It will be correct even if the
evacuation is still in progress or even if it is already finished.
Closes-Bug: #2085975
Change-Id: If5ad213649d68da995dad146f0a0c3cacc369309
The numa_policy field in the pci alias supports the same value as the
flavor extra_spec hw:pci_numa_affinity_policy but the config doc was not
updated when the socket value is implemented.
Closes-Bug: #2085824
Change-Id: I997d10638020fc9d60e784e64e395e6e0a9c9430
Makes igb vif model supported for hosts with libvirt 9.3.0 and qemu
8.0.0 or higher.
Implements: blueprint igb-vif-model
Depends-On: https://review.opendev.org/c/openstack/os-traits/+/928582
(merged, released as 3.2.0)
Change-Id: I6a1d8058c640e5dc015889610c4ae864ed9a5ccb
Qemu 8.0 and libvirt 9.3.0 added support for qemu emulated igb
network device. This patch adds the new igb value for hw_vif_model
so nova could eventually support booting VMs with such devices.
Subsequent patches will enable libvirt support.
Implements: blueprint igb-vif-model
Change-Id: I9c8dc1a663d0534d62798c5b4c8d4539551f7ae4
Our tox.ini sets the maximum complexity of a function to be 40. Adding
anything new to the ImageMetaProps.obj_make_compatible push it over the
limit. So this patch factors out common new field value checking logic
to a helper function to reduce the complexity before adding new supported
values.
As there was a small amount of this check in other ovos this patch does
the refactor across all nova ovos.
Change-Id: I828d91196ea06f4dc2823218f036960123446255
Since Hyper-V driver was removed, we don't expect any use case where
nova should be deployed in Windows OS. This scenario is no longer
tested since WinStackers project has been retired.
Drop the remaining code for Windows OS support to reduce unused code
and focus purely on linux systems.
Change-Id: I69b049d13556efe87f4be32f5e6e7f88e42f3b2a
The nodepool provides different VMs as computes it can have 8 or 4 cpus.
So the reverted commit breaks the test runs that uses 4 cpu computes. We
need a smarter solution and until then we need to get back to a stable
CI.
This reverts commit aca63b66e5.
Change-Id: Id48c6143533fa97f0b79936a4551f0e19751db44
The following volume drivers were marked unsupported in cinder, and
subject for removal in future releases.
- Quobyte: 2c1a77056672b35d51ef15242d59a2d81d8a7696
- Windows SMB: c690fe7cbd0d307d92689f4fae03423aa7a91157
- Virtuozzo: cf01d7eaf370485fe3fb834a3bcad13b0773b6e1
Deprecate the libvirt volume drivers specifically used for these
backends, so that we can remove the corresponding volume driver code
from nova when cinder removes these drivers.
Change-Id: Ib5b2fbc3fbf1c076ab1eec611b471f16a5b71c06
Get the shared security groups the tenant has access to by making an
additional Neutron API call with the shared filter, if loaded.
Depends-On: https://review.opendev.org/c/openstack/neutron/+/811242
Related-Bug: #1942615
Implements: blueprint shared-security-groups
Change-Id: I6f2847e89a8e4c32ab7c992d6da229f820c4988d
We dropped use of these some time ago but forgot to remove them from the
'doc/requirements.txt' file. Fix that oversight now.
Change-Id: I88e5e12d18264ce848457191ba3de2fbd8d8bf5c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This change updates resource provider trait list for hw architecture and
hw emulation architecture
Closes-Bug: #2062425
Change-Id: Ia571c5e5e881162d331b638ae2d4a332807d17f5
Python 3.8 is no longer part of tested runtimes since 2024.2 . Removing
support for Python 3.8 allows us to replace deprecated md5 wrapper from
oslo.utils [1] by direct call of hashlib.md5.
[1] https://review.opendev.org/c/openstack/oslo.utils/+/930879
Also add python 3.12 to classifiers because now py312 unit test job is
voting.
Change-Id: I53da305538e27f2ff20a1ecb25960ebb03388011
Long ago, it was decided that we should create an empty image in
glance for snapshots of volume-backed instances[1]. I'm not really sure
why that is, since it doesn't seem to be a useful construct to do
anything with (like a normal snapshot, which can be used to boot).
It was so long ago that it was not documented well[2]. However, when
glance v2 came along, that sort of nonsensical thing became harder
because images would not be "active" until they had content, and nova
decided to continue the status quo by uploading empty data[3] to
force the state transition. Later, that stopped working for Xen
because we were lying about the format in a way that didn't work for
Xen, so we made that lie dynamic[4] to triple-down on the original
decision.
Now, with glance moving to image format safety, our lies have caught
up with us. We can no longer upload an empty stream of data and claim
that it is qcow2 because glance will call our bluff. Although it was
originally suggested[5] as a fix that would be hypervisor-neutral (and
not implemented that way for reasons that were not stated), we must
start uploading that empty stream as the 'raw' format that it is in
order for glance to accept it. Technically glance can be configured
to not allow raw uploads, which means that we could again end up
with the situation from the xen bug[5], but without synthesizing a
fictitious image of a type that is supported, there's no good solutuon,
other than a re-think.
I think it would be worth revisiting whether or not we need an empty
glance image for volume-backed server snapshots, and if we do, whether
or not there's a better way to go about that (like adding a location
which will indicate it lives elsewhere and will result in it becoming
active). However, in the meantime we need to be truthful about the
lie we're making, by correctly identifying the format of the zero-
length data we're not uploading.
Needed-By: https://review.opendev.org/c/openstack/glance-specs/+/925111
Change-Id: I6a6184da3b73506261c61005b6984c69cdc7fb98
1: https://github.com/openstack/nova/commit/c3476b5ca7ab5237d3cb8a84fcb7a3292237b764
2: https://bugs.launchpad.net/nova/+bug/1034730
3: https://github.com/openstack/nova/commit/4a39b8b530b32337749a9e2d2a438b7b2f3430d8
4: https://github.com/openstack/nova/commit/2fe5daeb5fcd2750b0eb083fc5c8bfd3fdb992e2
5: https://bugs.launchpad.net/nova/+bug/1616938/comments/1
Note: Initially this patch was related to new feature, but now it has
become a bug since os-brick's `setup` method is not being called and it
can create problems if os-brick changes.
As a new feature, os-brick now supports setting the location of file
locks in a different location from the locks of the service.
The functionality is intended for HCI deployments and hosts that are
running Cinder and Glance using Cinder backend. In those scenarios the
service can use a service specific location for its file locks while
only sharing the location of os-brick with the other services.
To leverage this functionality the new os-brick code is needed and
method ``os_brick.setup`` needs to be called once the service
configuration options have been loaded.
The default value of the os-brick ``lock_path`` is the one set in
``oslo_concurrency``.
This patch adds support for this new feature in a non backward
compatible way, so it requires an os-brick version bump in the
requirements.
The patch also ensures that ``tox -egenconfig`` includes the os-brick
configuration options when generating the sample config.
Closes-Bug: #2081859
Change-Id: I1b81eb65bd145869e8cf6f3aabc6ade58f832a19
Add file to the reno documentation build to show release notes for
stable/2024.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.2.
Sem-Ver: feature
Change-Id: If5ecb630ece21c7cfc9357820a9a6b9ddcad5c42
Ghanshyam Mann