Skip to content

v1.0.1 - Fixes from live-fleet testing

Choose a tag to compare

@sameeralam3127 sameeralam3127 released this 12 Jul 16:16
· 4 commits to main since this release

Fixes found by running playbooks/baseline.yml / playbooks/postcheck.yml against a real 10-node Ubuntu fleet (Multipass) for the first time -- none of these were reachable from the macOS-only testing available during initial development.

Fixed

  • Service-name resolution was non-deterministic. Every <candidates> | intersect(<present services>) | first lookup (time-sync, sssd, systemd-journald) used intersect(), whose result order is not guaranteed to follow either input list -- it could return a different match on every run against the identical host state, occasionally picking a present-but-inactive unit (e.g. ntp.service, stopped) over the actually-running one. Replaced with <candidates> | select('in', <present services>) | list | first, which deterministically preserves the candidate list's priority order.
  • linux_vitals_time_sync_candidates never included Debian/Ubuntu's actual service names. It only listed chronyd* (RHEL's name) and ntp*, missing chrony.service/chrony (the real unit installed by Debian/Ubuntu's chrony package) and systemd-timesyncd.service/systemd-timesyncd (Ubuntu's out-of-the-box default). Every stock Ubuntu host was reporting a false "chronyd or ntp is not installed" finding despite systemd-timesyncd running the whole time. Both are now in the candidate list.
  • Systemd alias units report state: active, not state: running. chronyd.service is often a symlink alias to chrony.service on Debian/Ubuntu; ansible.builtin.service_facts reports alias units with state: active rather than running. The sssd/systemd-journald/time-sync "is it up" checks, and the self-healing restart-success check, only accepted running and treated a perfectly healthy aliased service as down. Both now accept state in ['running', 'active'].
  • Same-task variable self-reference in bootloader validation. linux_vitals_bootloader_validation_message referenced linux_vitals_bootloader_default_matches_latest from within the same set_fact call that defined it -- Ansible templates every key in a set_fact dict against the variable context that existed before the task ran, so this was always undefined at evaluation time. It only surfaced as a hard failure once bootloader detection actually reached status: resolved (i.e. on a real host with working grubby/grub2-editenv, never on the macOS dev machine). Split into two sequential tasks.