2
0
mirror of https://github.com/xcat2/xcat-core.git synced 2026-10-21 23:28:19 +00:00
Files
xcat-core/xCAT-test/unit
Daniel Hilst 28dc05c226 fix(xcat-server): a service node that mounts /install serves no NFS
servicenode.nfsserver=1 asks a service node to set up file services for the nodes behind it.
With site.installloc set, AAsn.pm mounts the install directory from the management node and
exports nothing, and setup_NFS only starts the daemon, so the service node serves no NFS at all.
Only the branch where installloc is unset ever wrote an export.

An Ubuntu compute node boots the live installer with casper, which mounts the install tree over
NFS from its own service node. Measured on xcat22-cn: the boot arguments carried
nfsroot=192.168.222.21:/install/ubuntu24.04.4/x86_64, and the node stopped at "(initramfs) Unable
to find a live file system on the network". On xcat22-sn, showmount -e returned an empty list and
/etc/exports was empty while nfs-kernel-server was active. EL never needed this, because anaconda
fetches over http.

setup_NFS now exports the install directory when nothing exports it yet, then runs exportfs after
the daemon. Re-exporting an NFS mount is not the same as exporting a local directory: the kernel
cannot derive a filesystem id for one and refuses the export without an explicit fsid, so
nfs_export_line adds fsid and crossmnt when the directory is itself a mount. The fsid comes from
the path, so a restart does not hand clients a new filesystem identity.

An export the kernel refuses is reported and does not fail the service node. The EL cell is
re-run on this tree, because an EL service node now writes an export it did not write before.

svrutils_nfs_export_line.t drives the routine. Five mutations were tried and each one fails the
assertions that name it.

Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
2026-09-29 16:15:40 -03:00
..

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.