docs: record Serenity Newt and wave 1 verification
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
secret-guardrails / gitleaks (push) Has been cancelled

This commit is contained in:
Fizzlepoof
2026-05-25 19:37:36 +00:00
parent 493f3253b8
commit cd98fcf49a
2 changed files with 29 additions and 1 deletions

View File

@@ -302,3 +302,29 @@ After wave 1, Serenity should still be alive for the workloads that currently ju
- stale created/exited clutter gone
That leaves a cleaner host and a safer runway for the later PD storage cutover and full Serenity retirement.
## Wave 1 verification results (2026-05-25)
Verified during this planning pass:
- Serenity still has these live containers relevant to wave 1:
- `technitium-dns-pilot`
- `binhex-official-pihole`
- `pihole-serenity`
- `unbound-pihole-serenity`
- `keepalived-pihole-serenity`
- `Newt`
- `Unraid-Cloudflared-Tunnel`
- PD still runs the primary Technitium stack plus its own Pi-hole and Newt lane.
- From NOMAD, `/etc/resolv.conf` currently lists `10.5.30.8`, `10.5.30.9`, and `10.5.30.10` ahead of external fallback `9.9.9.9`.
- From NOMAD, `dig` to `10.5.30.8` and `10.5.30.10` succeeded for public DNS resolution; same-host checks to `10.5.30.9` were unreliable, matching the existing macvlan caveat in the docs.
- `Unraid-Cloudflared-Tunnel` is still running, but repo docs already classify it as dead/stale and its container has `Restart=no`.
- Serenity `Newt` must not be treated as deadwood: operator confirmed Pangolin tunnels Serenity resources through Serenity's local Newt instead of routing from PD or NOMAD to Serenity resources over the Serenity LAN IP.
- Live Serenity `Newt` logs still show repeated Pangolin health checks against stale `10.5.1.5` targets (`7474`, `8785`, `8787`, `8788`, `8990`, `8457`, `5690`, `5454`).
Operational implication:
- removing Cloudflared remains low-risk after one final dependency check
- removing the legacy Pi-hole stack remains appropriate
- removing Serenity `Newt` is not appropriate during wave 1
- Pangolin target drift for Serenity-hosted resources should be repaired later by rehoming those resources to the correct Serenity site/local-path model instead of stale literal pre-migration IPs

View File

@@ -18,6 +18,7 @@ Current NAS, media-ingestion, and CPU-based AI helper host. Planned to retire af
- **NAS** — primary storage for Docker volumes, media, and backups via NFS
- **Media ingestion** — full ARR stack (Sonarr, Radarr, Prowlarr, qBittorrent, etc.)
- **Reranker host** — CPU-based TEI reranker for the AI RAG pipeline
- **Pangolin site host** — Serenity's local Newt is intentionally kept because Pangolin tunnels Serenity resources through that Newt instead of targeting Serenity resources from PD or NOMAD over Serenity LAN IPs
## Services
@@ -72,5 +73,6 @@ Serenity hosts the secondary backup Technitium node on `10.5.30.10`.
## Planned future role
- Transitional only; do not design new long-term dependencies around Serenity.
- Near-term it continues to host storage locality, reranker, and the backup Technitium node.
- Near-term it continues to host storage locality, reranker, the backup Technitium node, and the Serenity-local Newt needed for Pangolin access to Serenity resources.
- Once PD directly owns the storage, qBittorrent/ARR locality should move to PD and Serenity should be drained and retired.
- Before any Pangolin cleanup, re-home Serenity resources away from stale literal-IP targets; live Newt logs show repeated health checks to old `10.5.1.5` addresses.