v0.2.9

v0.2.9 — a roll stops breaking the peers' probes

A roll replaces nodes, and replaced nodes present new SSH host keys. Only the hypervisor that ran the roll learned them; every other hypervisor kept the old ones, so its peer probe failed on a key mismatch and degraded to [ -- ] without ever saying why. The probe looked like it was running. It was refusing to connect.

Fixed

• bug-177 — the host keys are scanned once, from one vantage, and the same lines are then installed on every hypervisor, so the fleet trusts one set of keys rather than each host accepting whatever it is shown first. scan_host_keys, install_host_keys and refresh_client_access are called from the roll and from both rebuild paths. The addresses are passed as positional parameters, never interpolated into the script — a test passes 10.99.0.21; rm -rf / as a node address and asserts no address appears in the script text.
• bug-179 — deploy-updates --repo . no longer needs the fleet to preview. The dry run plans a placeholder where the kubeconfig goes and says so; the fetch happens only under --apply, and an apply whose kubeconfig was never fetched refuses rather than writing the placeholder to a host.

Added

• deploy-updates joins the other two in the CI preview step, in both workflows. All three deploys now plan against the fixture site after every build, which is what bug-179 was blocking.

Operator notes

• install.sh v0.2.9 on each host. No --apply is required: every shipped file is byte-identical to v0.2.8, and the two fixes are in code paths the roll and the rebuild take.
• The bug-177 fix lands on the next roll. Until then, a host whose peer probe shows [ -- ] can be cleared by hand: ssh-keygen -R <node-ip> && ssh -o StrictHostKeyChecking=accept-new <admin>@<node-ip> true.

163 tests.