Due to bug 1802143, devstack was ignoring variables set in the
$NOVA_CPU_CONF section of local_conf. Now that that bug has been fixed
(see the Depends-On) we can put those back in their rightful place.
This patch moves the [compute]resource_provider_association_refresh
setting, introduced via [1], accordingly.
[1] https://review.opendev.org/616033
Depends-On: https://review.opendev.org/672805
Change-Id: Ifa50748b6d6e91ac954d0a7a6060505fd45716d4
Related-Bug: #1802143
Nothing was ever setting the '_numa_topology_loaded' attribute which
means this caching has never worked. Just drop the idea entirely.
Change-Id: I67c1d96f5b7c7c2c171869fbd54392d118b735af
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Migrations are resizes but with the same flavor so we use the
'revert_resize' function to revert a migration also. This isn't at all
obvious though so update the docstring to highlight this fact.
Change-Id: I96bc890a28991ddee3c672fc127956ec267afea0
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
- Add missing coverage for 'iptables_set_rules' and 'iptables_get_rules'
- Use a class-level mock for common mocks
- Use 'fixtures.MockPatch' instead of 'fixtures.MonkeyPatch'
- Move exception handling for the 'ovs_plug' and 'ovs_unplug' functions
to the functions themselves, allowing us to include the full command
attempted in the exception message
- OvsConfigurationFailure is renamed to OVSConfigurationFailure
Change-Id: Ib8bb847598db2a6b8de95fdb222279cd22eaabcc
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Currently, the 'purge_db' call occurs before 'set -e', so if and when
the database purge fails (return non-zero) it does not cause the script
to exit with a failure.
This moves the call after 'set -e' to make the script exit with a
failure if the database purge step fails.
Closes-Bug: #1840967
Change-Id: I6ae27c4e11acafdc0bba8813f47059d084758b4e
The url option was deprecated in Queens:
I41724a612a5f3eabd504f3eaa9d2f9d141ca3f69
The same functionality is available in the
endpoint_override option so tests and docs
are updated to use that where they were using
url before.
Note that because the logic in the get_client
method changed, some small changes were made to
the test_withtoken and test_withtoken_context_is_admin
unit tests to differentiate from when there is a
context with a token that is not admin and an
admin context that does not have a token which
was otherwise determined by asserting the default
region name.
Change-Id: I6c068a84c4c0bd88f088f9328d7897bfc1f843f1
The functional test setup already implemented in
test_shared_resource_provider.py and test_report_cpu_traits.py were
near identical, and the same approach is also needed by future tests
in the AMD SEV patch series, so extract it into a new base class
called LibvirtProviderUsageBaseTestCase in a new file:
nova/tests/functional/libvirt/integrated_helpers.py
and change the existing tests to use that.
blueprint: amd-sev-libvirt-support
Change-Id: I84375954cd1e6338b5ef857cf620616aee32bcc7
Currently we're only calling libvirt's getDomainCapabilities API once
per architecture, with the assumption that covering a single machine
type (the default) for that architecture is enough. However, the
default for x86_64 is 'pc', but we need domain capabilities for 'q35'
in order to allow guests with SEV or Secure Boot enabled. So for
x86_64, we need domain capabilities for at least two machine types:
'pc' and 'q35'.
We can obtain a sensibly small list of machine types with which to
call getDomainCapabilities by looking for the 'canonical' attribute in
machine types returned from getCapabilities (N.B. not
getDomainCapabilities). For example, getCapabilities returns these:
<machine canonical='pc-i440fx-2.11' maxCpus='255'>pc</machine>
<machine canonical='pc-q35-2.11' maxCpus='288'>q35</machine>
So change Host.get_domain_capabilities() to call the API not just with
the default machine type, but also once per canonical machine type.
In order to obtain the canonical machine types, enhance config.py so
that it can extract them from the capabilities XML, modernize the
fixtures for i686 and x86_64 capabilities so that they include recent
versions of the 'pc' and 'q35' families of machine types, and add
corresponding tests. A new class LibvirtConfigCapsGuestDomain is
introduced to model the elements of the capabilities XML such as
<domain type='kvm'>, and their associated machine types. This
supersedes the previous domtype attribute of LibvirtConfigCapsGuest
objects. Canonical machine types are tracked separately from the
others in order to allow Host.get_domain_capabilities to invoke
libvirt's getDomainCapabilities only on those types.
As before, we register both the shortened canonical (alias) machine
type (e.g. 'q35') plus its full expanded counterpart (e.g. 'pc-q35-2.11')
if that is different.
As Host.get_domain_capabilities() is already long and complex, and
needs more functionality adding to support these changes, split out
much of the code into smaller methods:
- _get_machine_types()
- _add_to_domain_capabilities()
The new tests require the allow_mixed_nodes option of assertXmlEqual
to be enabled to compare XML fragments with elements in different
orders, since the children of <arch> generated by
LibvirtConfigCapsGuest.format_dom have the non-canonical machine types
first, followed by the canonical ones.
The tests also require removing the 'bamboo' canonical machine type
for the ppc architecture, since the getDomainCapabilities fixture for
this architecture is static and only returns results with a fixed
'g3beige' machine type which would cause a mismatch when called with
the 'bamboo' machine type. The same applies with the 'q35' canonical
machine type for the i686 architecture, since the static fixture for
i686 only returns results with a fixed 'pc-i440fx-2.11' machine type.
However, the x86_64 fixtures are sufficient to test these code paths,
so this is a simpler alternative to adding complexity to the i686 and
ppc fixtures.
blueprint: amd-sev-libvirt-support
blueprint: allow-secure-boot-for-qemu-kvm-guests
Change-Id: I9da9ce682dc8c8b72fb31dd4e732b556b2ed7f90
LibvirtConfigGuestMemoryTune created a <memtune> element with
attribute "units", although the libvirt docs mention that it should be
"unit":
https://libvirt.org/formatdomain.html#elementsMemoryTuning
It did not cause any issues because libvirt actually accepts both,
but domains defined using "units" are automatically converted to
use "unit".
Similarly, libvirt will automatically convert "K" to "KiB".
So rename the attribute from "units" to "unit", and use the same "KiB"
unit format as elsewhere in the code, e.g. LibvirtConfigCapsNUMACell
and LibvirtConfigGuestMemoryBackingPage.
Change-Id: I1e5a28cd30124a2b08ed732d45e5504b31c97284
fakelibvirt.Connection.getCapabilities() spoofs a response to the
libvirt getCapabilities API call by hardcoding a large XML response
within itself. Split this XML response into smaller fragments and
move them to separate variables within the recently introduced
fake_libvirt_data class so that other tests (in particular an imminent
patch for the benefit of SEV and Secure Boot which tracks libvirt
host/domain capabilities for multiple machine types) can reuse them
individually.
This has some side benefits on readability: it makes much easier to
see the overall structure of the fake <capabilities> element at a
single glance without having to scroll through pages of XML, it avoids
bloating code by mixing in large chunks of static data, and it also
places the fake capabilities data next to the fake domain capabilities
data, which is useful given the relationships between the two.
blueprint: amd-sev-libvirt-support
Change-Id: I08f9069a7735bf3a705e6bedf9defad58b9ac7e8
Add a hacking rule for non-existent mock assertion methods and
attributes.
[N364] Non existent mock assertion method or attribute (<name>) is used.
Check a typo or whether the assertion method should begin with
'assert_'.
Change-Id: Ic6860e373120086a1a2ae9953f09a7bbaa032a7b
Eric Fried