michal/lab
1
0
Fork 0
Code Issues Pull Requests 3 Actions Packages Projects Releases Wiki Activity

PPPOE-HA: step 8 done -- model merged, zero drift
Some checks failed
CI/CD / typecheck (push) Failing after 9s
Details
CI/CD / test (push) Failing after 9s
Details
CI/CD / lint (push) Failing after 22s
Details
CI/CD / build (push) Has been skipped
Details
CI/CD / publish-rpm (push) Has been skipped
Details
CI/CD / publish-deb (push) Has been skipped
Details

Browse Source 
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.
This commit is contained in:
Michal
2026-09-06 09:42:12 +01:00
parent e1c571d004
commit d08f68e28b
1 changed files with 8 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
migration/PPPOE-HA.md
View File

@@ -2,7 +2,8 @@
Proven in labsim. **Deployed to production 2026-09-06** — mechanism on both Proven in labsim. **Deployed to production 2026-09-06** — mechanism on both
routers, `pppoe0 disable` removed from vyos002, vyos002 out of FAULT and in 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 ## 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 any hand commit to the pppoe subtree, `save` — or the next reboot produces a
standby that can never take over. 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. 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 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 **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" 2026-09-02 and predates this work). See "Outstanding: vyos001's config.boot"
below — it self-heals, but it should still be fixed. below — it self-heals, but it should still be fixed.
8. **Only now** merge `migration/pulumi-override-pppoe-gated.json` into 8. **Done 2026-09-06** (`kubernetes-deployment@45033dd`, on `main`). Both
`kubernetes-deployment` `infra/vyos/subtrees/overrides.json`. It is staged overrides merged, transition-scripts applied to both boxes by hand rather
here, unapplied, on purpose: another agent runs `pulumi up` on that repo, so 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 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 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 lets it dial on the next commit and take the single Vodafone session off