We have a load of tests to enable specific behavior depending on the
guest architecture, but in many cases we're actually testing the host
architecture. This is wrong and breaks our ability to create guests with
non-host architectures plus our ability to rely on mocking of these APIs
by 'FakeLibvirt'. We fix this by switching checks against the CPU
architecture reported by libvirt's host capabilities, to checks against
the guest image metadata (via 'nova.virt.libvirt.utils.get_arch') with a
fallback to the host architecture (via 'os.uname'). This seemingly
simple change subsequently highlights *a lot* of gaps in the mocking
done by 'FakeLibvirtFixture'. Pretty much all of these stem from the
fact that by previously extracting the CPU host architecture from host
capabilities, we were in practice almost always checking against x86-64.
Now that we're doing checks against image metadata with a fallback to
'os.uname()', we suddenly need to be able to provide host and domain
capabilities for other architectures and doing additional mocks for some
of these architecture-specific code paths.
Note that this change effectively removes test coverage for the
'LibvirtDriver._has_uefi_support' helper because we now mock it in the
'FakeLibvirtFixture' to avoid checks in AArch64 tests (AArch64 defaults
to a UEFI bootloader). This is okay since we're going to remove this
helper entirely in a future change.
Also note that this _still_ isn't as complete as I'd like it to be,
owing to time constraints and the sheer depth of the problem here. The
remaining issues will be addressed in follow-ups, potentially alongside
patches to drop support for legacy architectures like MIPS and I686 (the
former has been EOL'd in favour of RISC-V as of March 2021 and both
Intel and AMD stopped manufacturing products using the latter ISA for
anything other than embedded use cases many moons ago).
Change-Id: I158dd70076ecdbef422ef08c11ce6a140c991537
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
452d2fb3a0