Daniel Hilst
349658d3d7
A node with arch=riscv64 got an x86_64 libvirt domain from mkvm. The node took a DHCP lease, received the riscv64 GRUB binary that nodeset staged, and could not run it. The firmware fell through to the empty disk and stopped, so both flat provisioning cases of the riscv64 cell failed with a node that never installed. build_xmldesc and build_diskstruct in xCAT-server/lib/xcat/plugins/kvm.pm read the architecture from the hypervisor cpumodel. The arch of the node was never read while the domain XML was built, so on an x86_64 hypervisor every guest was an x86_64 guest, whatever the node said. guest_arch_profile now takes the arch of the node as well, and returns the domain type, the <os> arch and machine, the firmware and the device settings that follow from them. A riscv64 node becomes a qemu domain with the virt machine type and UEFI firmware. It drops the parts the riscv64 virt machine has no controller for, or that libvirt refuses there: the pae, acpi and apic features, the SeaBIOS serial option, the ich6 sound card, the USB tablet, and the ide disk and hd* optical drive. libvirt resolves the emulator and the UEFI firmware files itself. POWER and x86_64 domains do not change. kvm_guest_arch.t drives build_xmldesc and build_diskstruct in a scratch package, stubbing only the routines that reach libvirt or the xCAT database, and asserts the domain and the disks of each architecture. Ten of its twenty assertions fail without this change. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com> (cherry picked from commit 8d149c856302c8016fb0ead31e9859fd5a1e9dff)
xCAT-test/unit
Unit tests. These run against the source tree only -- no xCAT installation, no running daemons, no management node.
They are executed on every pull request by the xcat_test GitHub Actions workflow,
which calls run_unit_tests() in github_action_xcat_test.pl:
prove -r xCAT-test/unit
You can run exactly the same thing from a clean checkout:
cd <xcat-core checkout>
prove -r xCAT-test/unit
What belongs here
A test belongs in unit/ when everything it needs is in the checkout: plugin and
library sources, kickstart/preseed/subiquity templates, postscripts, packaging
metadata. Such a test asserts on rendered output or module logic and reaches the
repository root through FindBin:
use FindBin;
use lib "$FindBin::Bin/../../perl-xCAT";
use lib "$FindBin::Bin/../../xCAT-server/lib/perl";
Because of those FindBin paths the tests only work from a source tree. The copy
installed under /opt/xcat/share/xcat/tools/autotest/unit is not a substitute --
../.. resolves to /opt/xcat/share/xcat/tools there and the tests die or silently
skip. The CI takes a copy of the checkout before the build for this reason; see
preserve_source_tree().
What does not belong here
Anything that needs an installed xCAT, a populated /install, a real service binary
or a live daemon. Those go in ../integration and run on
a management node through xcattest. Both suites run on every pull request -- the
workflow installs xCAT on the runner and then runs the ci_test cases against it --
so putting a test in integration/ does not cost it CI coverage. What differs is what
each suite is allowed to depend on, and that unit tests also run standalone from a
bare checkout with no xCAT at all.
The distinction matters because a test that needs an absent environment does not fail
-- it calls plan skip_all and reports as skipped. A handful of those in a suite of
several hundred assertions is easy to stop reading. Keeping the two kinds in separate
directories means a skip in unit/ is a real signal rather than routine noise.
Guarding on a source file, on the other hand, is fine and common here:
plan skip_all => "compute.subiquity.tmpl not found" unless -f $tmpl_path;
That guard never fires when the tree is intact.