From 3811282fc338666ce4f9660f19260a360010f37c Mon Sep 17 00:00:00 2001 From: Fizzlepoof Date: Mon, 25 May 2026 18:29:04 +0000 Subject: [PATCH] docs: record Serenity cleanup decisions --- docs/planning/SERENITY_DOCKER_AUDIT.md | 59 ++++++++++++++++++-------- 1 file changed, 41 insertions(+), 18 deletions(-) diff --git a/docs/planning/SERENITY_DOCKER_AUDIT.md b/docs/planning/SERENITY_DOCKER_AUDIT.md index 69f8951..954fd23 100644 --- a/docs/planning/SERENITY_DOCKER_AUDIT.md +++ b/docs/planning/SERENITY_DOCKER_AUDIT.md @@ -50,8 +50,8 @@ These are live today, but they are not good long-term reasons to keep Serenity a - current backup Technitium node on Serenity (`10.5.30.10`) - long-term: keep at least one off-PD backup resolver, but that does not have to remain on Serenity forever - `Newt` - - live on Serenity now, but docs only call out PD and NOMAD as the intended long-term Pangolin/Newt exposure lane - - verify whether this agent is still needed before keeping it + - live on Serenity now + - operator confirmed it is still needed, so it should be preserved during cleanup and only rehomed deliberately later - `Hawser` - helper/observability tooling, not a reason to preserve Serenity as a host role - `netdata` @@ -74,7 +74,7 @@ These should be treated as cleanup targets unless a specific live dependency is - `keepalived-pihole-serenity` - these are legacy DNS/HA remnants now that Technitium is the active resolver strategy - repo docs now describe the Technitium trio as the active DHCP-advertised internal DNS path - - unless some forgotten client or admin workflow still depends on them, these should be drained and removed + - operator confirmed Technitium covers the intended DNS role, so these should be treated as removable at the next cleanup window - `postgresql15` - `MariaDB-Official` - both are live, but they are suspicious because current docs position PD as the shared database home @@ -190,22 +190,45 @@ Once PD directly owns the relevant media/torrent datasets: - preserve only the intended backup-DNS failure-domain role off PD - decommission Serenity once no production path depends on it -## Approval questions +## Resolved operator decisions -1. Do you want to keep any of these as deliberate long-term Serenity residents, even after PD takes storage ownership? - - GameVault - - RomM - - Wizarr - - Shelfmark - - Notifiarr +Resolved on 2026-05-25: -2. Is the legacy Pi-hole stack on Serenity allowed to be removed once we confirm Technitium covers all intended DNS duties? - -3. Should Newt on Serenity be treated as a real long-term exposure path, or as cleanup unless we prove it is needed? - -4. Are GameVault / RomM considered "nice to keep somewhere" apps that should migrate to PD, or are they candidates to prune? - -5. Once PD owns the disks locally, is your preferred policy still: - - move qbit + ARR family to PD +1. No app should deliberately remain on Serenity once PD owns the disks locally. +2. Technitium covers the desired DNS role; the legacy Serenity Pi-hole stack should be treated as removable. +3. `Newt` on Serenity is still needed and should not be treated as cleanup. +4. `GameVault` and `RomM` should migrate rather than be pruned. +5. End-state remains: + - move qbit + ARR family to PD after storage cutover - leave no intentional production app role on Serenity - retire Serenity entirely + +## Remaining verification questions + +- Confirm whether anything beyond `GameVault` still depends on `postgresql15`. +- Confirm whether anything beyond `RomM` still depends on `MariaDB-Official`. +- Is `/mnt/user/appdate/reranker` intentional, or a typo that should be corrected before migration? + +## Database dependency findings + +Live inspection of container environments currently points to: + +- `GameVault` -> local `postgresql15` + - `DB_HOST=10.5.30.5` + - `DB_PORT=5432` +- `RomM` -> local `MariaDB-Official` + - `DB_HOST=10.5.30.5` + - `DB_PORT=3306` + +No immediate database dependency was surfaced from the quick live environment check for: + +- `Wizarr` +- `Shelfmark` +- `Notifiarr` + +Operational implication: + +- `postgresql15` should currently be treated as a `GameVault` dependency until proven otherwise. +- `MariaDB-Official` should currently be treated as a `RomM` dependency until proven otherwise. +- those databases can likely retire once their dependent apps are migrated to PD and verified there. +- the legacy Pi-hole containers can be scheduled for removal at the next cleanup window.