build-ubunturepo guarded builds with a single host-global, fail-fast lock at
/var/lock/xcatbld.lock (`flock -n`). Two builds on one host -- e.g. the devel and
stable Ubuntu CD lanes on xcat-master-ub -- therefore collided on that one lock and
the loser exited 1 with "Can't get lock ...", failing the whole pipeline, even though
each lane builds from its own checkout into its own DEST and they share nothing.
build-ubunturepo builds its packages in-place in its own source checkout (it rewrites
debian/changelog and debian/control, drops *.orig.tar.gz at the checkout root and runs
dpkg-buildpackage inside the package dirs), so the resource two concurrent builds
actually contend for is the checkout, not the host. Key the lock on the checkout path
($curdir): builds of the SAME checkout still fail-fast (they would corrupt each other
in-place), while builds of DISTINCT checkouts get distinct locks and run in parallel.
The lock file stays on the local /var/lock (reliable flock, unlike the NFS/virtiofs
checkout) and the source tree is left byte-pristine.
Add xCAT-test/unit/build_ubunturepo_lock.t, which extracts the lock block from the
script verbatim and asserts: the lock path is /var/lock/xcatbld-<hash-of-checkout>.lock
and deterministic per checkout; a second build of the same checkout fails fast; two
distinct checkouts acquire their locks concurrently.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Add a regression case to dhcp_kea_plugin_intent.t for a node whose mac
table entry uses the *NOIP* sentinel on a secondary NIC
("mac1|mac2!*NOIP*"). The mocked getipaddr resolves every name (including
the literal *NOIP*), so the only thing that can keep the node to a single
reservation is an explicit *NOIP* skip in kea_node_reservations() and
kea_node_reservations6(). The test asserts exactly one v4 and one v6
reservation, for the real NIC, with no reservation carrying *NOIP* as a
hostname -- covering both the "bogus second reservation" and the
"unresolved reservation aborts makedhcp" failure modes.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
merge_core_repos already assembles the multi-arch core and runs the full
finalize tail (index -> sign -> final metadata -> write_release_alias, in the
required order so the xCAT-release-latest alias lands AFTER metadata and stays
out of the repo index). The preceding commit restored a separate finalize_core
sub purely to satisfy xcat_release_package.t, which grepped for
'sub finalize_core { ... $dir ... }'. That left two overlapping entry points:
--finalize-core (finalize one pre-assembled dir) and --merge-core-repos
(assemble N per-arch dirs THEN finalize) -- the former a strict subset of the
latter, with no in-tree or CI caller.
Consolidate on the single assemble+finalize path: inline the finalize tail into
merge_core_repos, drop sub finalize_core and the --finalize-core getopt/dispatch,
and update xcat_release_package.t to assert the stable alias is created after the
final metadata pass inside merge_core_repos ($out). Behaviour is unchanged (merge
already wrote the alias); only the redundant finalize_core interface is removed.
xcat_release_package.t 26/26; perl -c clean.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Boot URLs handed to nodes always carried an explicit :80 even when the HTTP
server listens on the default port. grub2.pm already omits the port when it is
80; make the xNBA, genesis and DHCP boot URLs consistent with it.
$portsuffix is empty when site.httpport is unset or 80 and ":<port>" otherwise,
so a non-default port is unchanged. Covers the ISC and Kea paths in dhcp.pm,
xnba.pm, mknb.pm, and the Kea xNBA client classes in BootPolicy.pm.
dhcp_boot_policy.t and mknb_xcatd_address.t follow the new URLs and gain cases
for a non-default and an unset port. The floating-address guard in
mknb_xcatd_address.t also drops :80 so that it keeps matching.
Recovered from the unmerged lenovobuild branch (cd61fd9d, a2f77ea9, 1035841b,
b7db0e2, 792fe6d).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
noderes.netboot is parsed as grub2-<protocol> and validated with
/^http|tftp$/, which reads as (^http)|(tftp$) and so also accepts values
such as https, httpx and xtftp.
A value that passes but is not exactly "http" then falls through to
set root=$grub2protocol,$serverip, which drops site.httpport, so the mistake
surfaces as a confusing grub2 failure at boot instead of the "Invalid netboot
method" error this check exists to give. grub2-https cannot work in any case,
since only "insmod http" is emitted.
Supported values are unchanged: grub2, grub2-http and grub2-tftp.
wait_for_provision caps how long retry_install polls for a node to reach
'booted' after each rinstall. Measured healthy provisions in devel-cd #22 boot
well inside this window (diskless ~6-8 min, diskfull ~8-16 min), so 30 min was
mostly slack that only lengthened the give-up time on a genuinely failing node.
Drop it to 20 min: still above the ~16-min diskfull install, while shrinking each
failed attempt's cost (6 min fixed sleep + 20 poll = 26 min vs 36). Combined with
the 3->2 attempt default, a fully-failing case's retry stack drops substantially.
Trade-off noted: the margin over a slow-under-load diskfull install is now tighter.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
retry_install.sh retries a node provision $times (default 3) x 30 min. The flat
diskless/diskfull cases each call it multiple times, so when a node genuinely
fails to come up the retries stack to ~3.5-4 h per case (measured: a single
contention-flaked el8-x86 diskless burned 14181s in devel-cd #22), which both
balloons the CD wall-clock and delays the red verdict.
Two attempts still absorbs a one-off transient (a single slow/failed netboot)
while halving the worst-case retry time (3->2 tries per call). Callers that pass
an explicit count (e.g. the negative-provision check that passes 1) are
unaffected -- only the default changes.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Vinícius Ferrão
Vinícius Ferrão
Daniel Hilst