fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record Serenity cleanup decisions
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
Details
secret-guardrails / gitleaks (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Fizzlepoof
2026-05-25 18:29:04 +00:00
parent 05ad5cb27a
commit 3811282fc3
1 changed files with 41 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
docs/planning/SERENITY_DOCKER_AUDIT.md
View File

@@ -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`) - 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 - long-term: keep at least one off-PD backup resolver, but that does not have to remain on Serenity forever
- `Newt` - `Newt`
- live on Serenity now, but docs only call out PD and NOMAD as the intended long-term Pangolin/Newt exposure lane - live on Serenity now
- verify whether this agent is still needed before keeping it - operator confirmed it is still needed, so it should be preserved during cleanup and only rehomed deliberately later
- `Hawser` - `Hawser`
- helper/observability tooling, not a reason to preserve Serenity as a host role - helper/observability tooling, not a reason to preserve Serenity as a host role
- `netdata` - `netdata`
@@ -74,7 +74,7 @@ These should be treated as cleanup targets unless a specific live dependency is
- `keepalived-pihole-serenity` - `keepalived-pihole-serenity`
- these are legacy DNS/HA remnants now that Technitium is the active resolver strategy - 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 - 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` - `postgresql15`
- `MariaDB-Official` - `MariaDB-Official`
- both are live, but they are suspicious because current docs position PD as the shared database home - 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 - preserve only the intended backup-DNS failure-domain role off PD
- decommission Serenity once no production path depends on it - 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? Resolved on 2026-05-25:
- GameVault
- RomM
- Wizarr
- Shelfmark
- Notifiarr
2. Is the legacy Pi-hole stack on Serenity allowed to be removed once we confirm Technitium covers all intended DNS duties? 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. Should Newt on Serenity be treated as a real long-term exposure path, or as cleanup unless we prove it is needed? 3. `Newt` on Serenity is still needed and should not be treated as cleanup.
4. `GameVault` and `RomM` should migrate rather than be pruned.
4. Are GameVault / RomM considered "nice to keep somewhere" apps that should migrate to PD, or are they candidates to prune? 5. End-state remains:
- move qbit + ARR family to PD after storage cutover
5. Once PD owns the disks locally, is your preferred policy still:
- move qbit + ARR family to PD
- leave no intentional production app role on Serenity - leave no intentional production app role on Serenity
- retire Serenity entirely - 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.