What we have there is not a schema URI. Having a proper URI allows
auto-detection of the schema version (draft-07 in this case).
Change-Id: I208a05c7ba64a21ed8cde7bc1ebae2b5878109e0
This patch is a followup on 45c0a3884b
As agreed on the Nova weekly meeting [1], we won't put back C9S job to voting
and we'll rather put it on both experimental and periodic-weekly pipelines.
In order to insure we will monitor the status of those runs, we'll check
the status of the job during every Nova meeting happening weekly.
In order to trigger potential race conditions, it was acted to provide an
experimental job for C9S too.
[1] https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.log.html#l-52
Change-Id: I2de4d90202fd7e735026150f79409d51f2d70e0e
neutron now declares linuxbridge experimental and requires
it to be enabled by a new config option. We do not set
that in these jobs so the neutron server fails to load
since we enable the linux bridge mech driver.
we do not actully use linuxbridge in these jobs so this patch
just disables the mech driver.
Change-Id: I129a850c3327498d26d899c7709f5749622afdd8
Closes-Bug: #1980948
Added function '_check_machine_type' which accept host
capabilities (caps) and machine type as param and look
for machine type in host caps object, if machine type
is not found raises exception InvalidMachineType
Closes-Bug: #1933097
Change-Id: I59d22c0342d6b0f3c0398ce62ec177dae39b5677
This change simply catches the exception raised when
we lookup a servergroup via a hint and the validation
upcall is enabled.
Change-Id: I858b4da35382a9f4dcf88f4b6db340e1f34eb82d
Closes-Bug: #1890244
This change adds a test to simulate validating
a instnace group policy where the group has been
deleted but is still referenced in the scheduler hint.
Change-Id: I803e6286a773d9e53639ab0cd449fc72bb3be613
Related-Bug: #1890244
This change removes return statement from rpc cast method calls.
As rpc cast are asynchronous, so doesn't return anything.
Change-Id: I766f64f2c086dd652bc28b338320cc94ccc48f1f
Due to the bug below, all the nova patches are failing. I accordingly
propose to make the job non-voting as it would allow our gate to ressurect.
Of course, this is a transient solution and we need a proper fix for the
job in order to have Centos 9 Stream support back in place ASAP.
When the job is back OK, please make it voting again by reverting this patch.
Change-Id: I5c3fff65fd6d9e4f3632d1ec62ae3f1f9cfbe626
Related-Bug: #1979047
When cinder-api runs behind a load balancer(eg haproxy), the load
balancer can return 504 Gateway Timeout when cinder-api does not
respond within timeout. This change ensures nova retries deleting
a volume attachment in that case.
Also this change makes nova ignore 404 in the API call. This is
required because cinder might continue deleting the attachment even if
the load balancer returns 504. This also helps us in the situation
where the volume attachment was accidentally removed by users.
Closes-Bug: #1978444
Change-Id: I593011d9f4c43cdae7a3d53b556c6e2a2b939989
The TooOldComputeService upgrade check currently produces a warning,
which may be missed if the upgrade process only checks the exit code of
the upgrade check command.
Since this can lead to Nova control services failing to start, make the
upgrade check a failure instead, so it results in a non-zero exit code.
Closes-Bug: #1956983
Change-Id: Ia3ce6a0b0b810667ac0a66502a43038fe43c5aed
_fake_do_delete function from nova/tests/unit/compute/test_api.py is
called with reservations=None argument. This argument is no longer used
in _local_delete. Since_fake_do_delete function is not really used
because it only contains pass statement, we can replace it with no op
call implemented using lambda function.
Change-Id: Idf9686afeadc2d000c3bc255e809c914967a063f
Because in the above description:
To install nova-compute, run:
PS C:\> cd c:\nova
PS C:\> python setup.py install
The file is downloaded to c:\nova. After executing `python setup.py
install` in this directory, the etc directory is generated under
`c:\nova`. Correct the path.
Closes-Bug: #1964548
Change-Id: Ibf0c1b56f235fffae65afbbcee30056bae965afe
Change [1] added new fields 'src|dst_supports_numa_live_migration'
to LibvirtLiveMigrateData object, but missed if condition for
dst_supports_numa_live_migration field in obj_make_compatible
method.
This change adds the if condition as well as fix typo in unit test
because of which this wasn't catched earlier.
Closes-Bug: #1975891
Change-Id: Ice5a2c7aca77f47ea6328a10d835854d9aff408e
The libvirt virt dirver checks the AMD KVM kernel module parameter SEV
to see if that feature is enabled. However it seems that the
/sys/module/kvm_amd/parameters/sev file can either contain "1\n" or
"Y\n" to indicate that the feature is enabled. Nova only checked for
"1\n" so far making the feature disabled on compute nodes with "Y\n"
value. Now the logic is extended to accept both.
Closes-Bug: #1975686
Change-Id: I737e1d73242430b6756178eb0bf9bd6ec5c94160
Nova's use of libvirt's compareCPU() API served its purpose
over the years, but its design limitations break live migration in
subtle ways. For example, the compareCPU() API compares against the
host physical CPUID. Some of the features from this CPUID aren not
exposed by KVM, and then there are some features that KVM emulates that
are not in the host CPUID. The latter can cause bogus live migration
failures.
With QEMU >=2.9 and libvirt >= 4.4.0, libvirt will do the right thing in
terms of CPU compatibility checks on the destination host during live
migration. Nova satisfies these minimum version requirements by a good
margin. So, provide a workaround to skip the CPU comparison check on
the destination host before migrating a guest, and let libvirt handle it
correctly. This workaround will be removed once Nova replaces the older
libvirt APIs with their newer and improved counterparts[1][2].
- - -
Note that Nova's libvirt driver calls compareCPU() in another method,
_check_cpu_compatibility(); I did not remove its usage yet. As it needs
more careful combing of the code, and then:
- where possible, remove the usage of compareCPU() altogether, and
rely on libvirt doing the right thing under the hood; or
- where Nova _must_ do the CPU comparison checks, switch to the better
libvirt CPU APIs -- baselineHypervisorCPU() and
compareHypervisorCPU() -- that are described here[1]. This is work
in progress[2].
[1] https://opendev.org/openstack/nova-specs/commit/70811da221035044e27
[2] https://review.opendev.org/q/topic:bp%252Fcpu-selection-with-hypervisor-consideration
Change-Id: I444991584118a969e9ea04d352821b07ec0ba88d
Closes-Bug: #1913716
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Signed-off-by: Balazs Gibizer <bgibizer@redhat.com>
Just because we encountered a PortNotFound error when unbinding a port
doesn't mean we should stop unbinding the remaining ports. If this error
is encountered, simply continue with the other ports.
While we're here, we clean up some other tests related to '_unbind_port'
since they're clearly duplicates.
Change-Id: Id04e0df12829df4d8929e03a8b76b5cbe0549059
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Closes-Bug: #1974173
The call to _get_pci_passthrough_devices could fail because a
network device could have disappeared which would cause a traceback
in the logs.
This wraps the function in a safe way to return an empty array
if it fails, which will clean-up the logs if the device disappears
Closes-Bug: #1972028
Change-Id: I46d3bbe122d9f8452f168286391bab67ecea3128
This change simply replaces calling notifyAll() with
notify_all() on the threading condition object in
the notification fixture.
notify_all() was introduced in python 2.6
Change-Id: If8d386f20693016dd35ecfdbc703bf31aa103a67
Patch fixing bug #1861071 resolved the issue of extending LUKS v1
volumes when nova connects them via libvirt instead of through os-brick,
but nova side still fails to extend in-use volumes when they don't go
through libvirt (i.e., LUKS v2).
The logs will show a very similar error, but the user won't know that
this has happened and Cinder will show the new size:
libvirt.libvirtError: internal error: unable to execute QEMU command
'block_resize': Cannot grow device files
There are 2 parts to this problem:
- The device mapper device is not automatically extended.
- Nova tries to use the encrypted block device size as the size of the
decrypted device.
This patch leverages the "extend_volume" method in os-brick connectors
to extend the device mapper device, after the encrypted device has been
extended, and use the size of the decrypted volume for the block_resize
operation.
Related change: I351f1a7769c9f915e4cd280f05a8b8b87f40df84
Closes-Bug: #1967157
Change-Id: Ia1411f11ec4bf44af6a42d5f96c8a0903846ed66
At the moment, if libvirt times out in detaching a device, it
reports this as an ERROR even if the process will be retried
and eventually succeed.
We should just log a warning since there's nothing to do, and
if the process fails after all the retries, it will log an ERROR
anyways.
Closes-Bug: #1972023
Change-Id: Idda12db5758706a97b7841571b9ecd3dc6e6905e
Dmitry Tantsur