Daniel Hilst
980b7de169
Appendix A rows 15 to 18, the remaining spec decisions where the two backends answered the same client differently. Row 15, a loader that is not on disk is not named. The ISC architecture chain named every loader unconditionally, so a client whose loader was never built spent a full TFTP timeout it could not diagnose; the Kea side had always left the class out. The chain is now built from a list of gated branches rather than a literal block, because dropping a branch from a literal if/else if chain can leave a leading "} else if", which dhcpd rejects outright. Row 16, a *NOIP* interface draws no reply. Kea discards a packet assigned to the class named DROP, and only one such class may exist, so every dropped MAC in the cluster shares it and the user-context records which node each belongs to. Syncing one node merges into that list and removing one node prunes only its own entries, so makedhcp for a single node cannot bring another node's interface back. Row 17, a node that boots from disk, and row 18, a node deferring to proxydhcp, are decided per node. Kea host reservations outrank every client class, so the reservation has to fall silent -- an empty boot-file-name -- and let the class carry the answer. Rows 19 and 20 landed earlier and dictated the same shape: the reservation names nothing and two mutually exclusive classes, one for the vendor and one for "not the vendor", decide between them, because Kea evaluates every class independently and has no else.
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.
Shell-script unit tests belong in ../bats
and run with BATS. Do not add Perl .t tests that grep shell source when the
behavior can be exercised by sourcing a shell library or script and shadowing the
external commands it calls.
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.