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
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>
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
The commit c1ccc1a316 introduced
a regression when NUMA live migration was done on shared storage
The live migration support for the power mgmt feature means we need to
call driver.cleanup() for all NUMA instances to potentially offline
pcpus that are not used any more after the instance is migrated away.
However this change exposed an issue with the disk cleanup logic. Nova
should never delete the instance directory if that directory is on
shared storage (e.g. the nova instances path is backed by NFS).
This patch will fix that behavior so live migration will function
Closes-Bug: #2080436
Change-Id: Ia2bbb5b4ac728563a8aabd857ed0503449991df1
This change ensures that if we are upgrading a
InstanceNUMACell object created before victoria
<1.5 that we properly set pcpuset=set() when
loading the object form the db.
This is requried to support instances with a numa
topology that do not use cpu pinning.
Depends-On: https://review.opendev.org/c/openstack/python-openstackclient/+/929236
Closes-Bug: #2080556
Change-Id: Iea55aabe71c250d8c8e93c61421450b909a7fa3d
This change reproduces a bug in the db load of old
instance numa toplogy json blobs in
_migrate_legacy_dedicated_instance_cpuset
that failed to account for defaulting pcpuset to
the empty set when it is not in the json blob.
Related-Bug: #2080556
Change-Id: Ia0f327c501f65786d5b2538b2742ec2786486956
For blank files that are created by nova such as swap
disks and ephemeral disks we do not need need to safety
check them as they always are just bare filesystems.
In the future we should refactor the qcow imagebackend to
not require backing files for swap and ephemeral disks
but for now we simply disable the check to workaround
the addition of the gpt image inspector and the incompatiblity
with vfat. future versions of oslo will account for vfat boot
recored. this is a minimal patch to avoid needing a new oslo
release for 2024.2
Closes-Bug: #2079850
Change-Id: I7df3d9859aa4be3a012ff919f375a7a3d9992af4
This commit add a functional repoducer for a regression
in ephmeral disk image format validation
When we changed to use the oslo.utils verison of the
format_inspector we aquired a new inspector which can
detect if a file has a partition table.
As the qcow 2 backend does not know that ephemeral disk
or swap disk are not boot able it requires that they
also have partition tables.
Related-Bug: #2079850
Change-Id: I26c6e8d2efbf7403542e99b8ac45e2a31f08afd1
At present, we can modify the properties in the instance
system_metadata through the sub command image_property of
nova-manage, but there may be inconsistencies between their
values and those in request_specs.
And the migration is based on request_specs, so the same image
properties are also written to request_specs.
Closes-Bug: 2078999
Change-Id: Id36ecd022cb6f7f9a0fb131b0d202b79715870a9
We agreed by I2dd906f34118da02783bb7755e0d6c2a2b88eb5d on the support
envelope.
Pre-RC1, we need to add a service version in the object.
Post-RC1, depending on whether it's SLURP or not SLURP, we need to bump
the minimum version or not.
This patch only focuses on pre-RC1 stage.
Given Epoxy won't be skippable, we won't need a post-RC1 patch for updating the min
that will continue to support Caracal.
HTH.
Change-Id: I9737a6ea02203605c1d36204b74fe3575764841e
We changed the code to ignore the file-name as
- a vmotion will result in renaming of the files
- booting from a volume names the volume by its uuid,
both breaking the heuristic to detect the root disk.
We simply take the first hard disk in the default boot-order.
If we boot from an ISO, it will be attached as a CD-ROM, not as a
disk. Any snapshots would be taken from the first actual disk, so it
still can be used as a method to install an OS to an empty disk.
Disks for rescue operations are attached later in the default
boot-order, but the boot order will be changed to allow booting from
that disk.
Closes-Bug: #2055411
Change-Id: Ib3088cfce4f7a0b24f05d45e7830b011c4a39f42
Since the commit the remove AMI snapshot format special casing
has merged, we're now running the libvirt snapshot tests as expected.
However, for those tests qemu-img binary needs to be installed.
Because these tests have been silently and incorrectly skipped for so long,
they didn't receive the same maintenance as other tests as the failures went unnoticed.
Change-Id: Ia90eedbe35f4ab2b200bdc90e0e35e5a86cc2110
Closes-bug: #2075178
Signed-off-by: Julien Le Jeune <julien.le-jeune@ovhcloud.com>
This change migrates the code currently written only to serve libvirt
driver to be generally useful, adding driver-neutral data structures
and a method to build them.
The libvirt driver is reworked to use get_instance_driver_metadata
instead of it's current code.
The ironic driver is reworked, per the blueprint, to send along some of
this additional metadata to the Ironic node.instance_info.
blueprint ironic-guest-metadata
Needed-By: https://review.opendev.org/c/openstack/ironic/+/924887
Change-Id: I2b23c8463f66c38e64625486157f245cd74cec61
Balazs Gibizer