From d08f68e28b0729941df23e275ddc7c82df50c308 Mon Sep 17 00:00:00 2001 From: Michal Date: Sun, 6 Sep 2026 09:42:12 +0100 Subject: [PATCH] PPPOE-HA: step 8 done -- model merged, zero drift Both overrides are on kubernetes-deployment main (45033dd) and the transition-scripts were applied to the boxes directly rather than left for an unattended `pulumi up` to find. vyos:verify reports both routers in sync. Also records the drill result in the header, since "deployed" and "proven to fail over" are different claims and only the second one is worth much. --- migration/PPPOE-HA.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/migration/PPPOE-HA.md b/migration/PPPOE-HA.md index 381d151..f586d46 100644 --- a/migration/PPPOE-HA.md +++ b/migration/PPPOE-HA.md @@ -2,7 +2,8 @@ Proven in labsim. **Deployed to production 2026-09-06** — mechanism on both routers, `pppoe0 disable` removed from vyos002, vyos002 out of FAULT and in -BACKUP. The Pulumi override (step 8) is still staged, not merged. +BACKUP, Pulumi model merged, and a controlled failover drill passed +(takeover 52s, failback 36s). `vyos:verify` reports both routers in sync. ## What it does @@ -111,7 +112,7 @@ sim secondary lost its WAN and spent hours looking like an ISP problem. After any hand commit to the pppoe subtree, `save` — or the next reboot produces a standby that can never take over. -## Deploying — steps 1–7 done 2026-09-06, 8–9 outstanding +## Deploying — steps 1–8 done 2026-09-06, 9 outstanding 1. `sudo /config/vyos-known-good save` on both. 2. `migration/vrrp-wan-install --vip 192.168.1.1 --host vyos@10.0.1.253` then the @@ -128,9 +129,11 @@ standby that can never take over. **It is not.** vyos002 has it; vyos001 does not (its `config.boot` dates from 2026-09-02 and predates this work). See "Outstanding: vyos001's config.boot" below — it self-heals, but it should still be fixed. -8. **Only now** merge `migration/pulumi-override-pppoe-gated.json` into - `kubernetes-deployment` `infra/vyos/subtrees/overrides.json`. It is staged - here, unapplied, on purpose: another agent runs `pulumi up` on that repo, so +8. **Done 2026-09-06** (`kubernetes-deployment@45033dd`, on `main`). Both + overrides merged, transition-scripts applied to both boxes by hand rather + than left as drift, and `vyos:verify` is clean: 533 / 512 nodes, zero drift. + The staging file `migration/pulumi-override-pppoe-gated.json` is kept as the + record of why the ordering mattered. It was staged, unapplied, on purpose: another agent runs `pulumi up` on that repo, so merging it *is* a production change made by someone else at a time you do not choose. Removing `pppoe0 disable` from vyos002 before the gate exists there lets it dial on the next commit and take the single Vodafone session off