Inventory application datasets on TrueNAS and prepare required NFS access #4

New issue

Closed

opened 2026-08-29 00:22:48 -05:00 by portegumi · 1 comment

portegumi commented

2026-08-29 00:22:48 -05:00

Collaborator

Description

Inventory the current TrueNAS application datasets and related node-local data before migrating workloads. The inventory records which workloads will move into Kubernetes, remain on TrueNAS, be replaced, or be retired so storage conventions and application issues are based on the actual environment.

The detailed, setup-specific inventory and migration order is documented in Mat Homelab Application Migration Plan.

Inventory outcome

Migrate to Kubernetes

Actual Budget
Forgejo Linux Actions runner
Trilium Notes
Node-RED
Jellyseerr
Audiobookshelf
Calibre and Calibre-Web
Reactive Resume
GitchAlerts
AFFiNE
Twenty CRM
Vaultwarden
Ghost
Forgejo
ERPNext
Core Keeper, Satisfactory, Windrose, Enshrouded, and Palworld game servers
ComfyUI
Jellyfin
Jellystat
Existing FoundryVTT instances through the new hosting platform in #19

Remain on TrueNAS or otherwise outside Kubernetes

MinIO
NocoDB
UDS Keycloak PostgreSQL dataset at homelab/postresql
qBittorrent and Gluetun
Sonarr, Radarr, Prowlarr, and FlareSolverr
Shared media library
ROM library after retiring the RomM application

Replace during migration

Authentik with UDS Keycloak
Pi-hole with Technitium DNS Server
Nginx Proxy Manager with Istio

Retire

Current TradeGumi deployment; redeploy the actively developed replacement when ready
Baserow
TrueNAS Core Keeper and Satisfactory instances
Readarr
Standalone Grafana
JDownloader
RomM application
Lidarr
n8n
Navidrome
Tailscale on TrueNAS
KitchenOwl
TrueNAS ComfyUI instance
Remark42

Storage classifications

Existing large shared datasets remain on TrueNAS and are exposed through static NFS where Kubernetes requires them.
Ordinary single-writer application state is copied or restored into dynamically provisioned iSCSI-backed RWO volumes.
Shared application state uses NFS-backed RWX volumes only when the workload requires multi-node or multi-writer access.
OptiPlex game data remains node-local while the game-server containers move into Kubernetes and are scheduled to that node.
ComfyUI data remains local to the RTX 3080 Ti media node.
Jellyfin configuration moves into Kubernetes while the media library remains on TrueNAS.
Services intentionally remaining on TrueNAS are consumed as external network services and are not represented as Kubernetes-owned PVC data.

Migration priority

Actual Budget establishes the application migration pattern.
Low-complexity applications and the Forgejo runner validate repeatable packaging, ingress, authentication, backup, and recovery.
Conventional database-backed applications follow.
Public and complex services follow after the pattern is proven.
Node-local game and GPU workloads migrate last.
The Foundry hosting platform proceeds as a separate product-development track after the base pattern is proven.

Acceptance criteria

A sanitized dataset and workload inventory is documented without credentials or sensitive file contents.
Each inventoried workload has an ownership and migration classification.
Required NFS access has been validated from designated cluster nodes.
Dynamic NFS and iSCSI provisioning, permissions, expansion, persistence, and reclaim behavior have been validated with disposable clients under #5.
Existing services remain operational while migration planning is completed.
The migration priority and node-local storage exceptions are documented.

Dependencies / blockers

This issue blocks #6. The dynamic provisioning approach was selected and validated under #5; #6 must now formalize conventions using this inventory.

## Description Inventory the current TrueNAS application datasets and related node-local data before migrating workloads. The inventory records which workloads will move into Kubernetes, remain on TrueNAS, be replaced, or be retired so storage conventions and application issues are based on the actual environment. The detailed, setup-specific inventory and migration order is documented in [Mat Homelab Application Migration Plan](/gitchegumi/homelab/wiki/Mat-Homelab-Application-Migration-Plan). ## Inventory outcome ### Migrate to Kubernetes - Actual Budget - Forgejo Linux Actions runner - Trilium Notes - Node-RED - Jellyseerr - Audiobookshelf - Calibre and Calibre-Web - Reactive Resume - GitchAlerts - AFFiNE - Twenty CRM - Vaultwarden - Ghost - Forgejo - ERPNext - Core Keeper, Satisfactory, Windrose, Enshrouded, and Palworld game servers - ComfyUI - Jellyfin - Jellystat - Existing FoundryVTT instances through the new hosting platform in #19 ### Remain on TrueNAS or otherwise outside Kubernetes - MinIO - NocoDB - UDS Keycloak PostgreSQL dataset at `homelab/postresql` - qBittorrent and Gluetun - Sonarr, Radarr, Prowlarr, and FlareSolverr - Shared media library - ROM library after retiring the RomM application ### Replace during migration - Authentik with UDS Keycloak - Pi-hole with Technitium DNS Server - Nginx Proxy Manager with Istio ### Retire - Current TradeGumi deployment; redeploy the actively developed replacement when ready - Baserow - TrueNAS Core Keeper and Satisfactory instances - Readarr - Standalone Grafana - JDownloader - RomM application - Lidarr - n8n - Navidrome - Tailscale on TrueNAS - KitchenOwl - TrueNAS ComfyUI instance - Remark42 ## Storage classifications - Existing large shared datasets remain on TrueNAS and are exposed through static NFS where Kubernetes requires them. - Ordinary single-writer application state is copied or restored into dynamically provisioned iSCSI-backed RWO volumes. - Shared application state uses NFS-backed RWX volumes only when the workload requires multi-node or multi-writer access. - OptiPlex game data remains node-local while the game-server containers move into Kubernetes and are scheduled to that node. - ComfyUI data remains local to the RTX 3080 Ti media node. - Jellyfin configuration moves into Kubernetes while the media library remains on TrueNAS. - Services intentionally remaining on TrueNAS are consumed as external network services and are not represented as Kubernetes-owned PVC data. ## Migration priority 1. Actual Budget establishes the application migration pattern. 2. Low-complexity applications and the Forgejo runner validate repeatable packaging, ingress, authentication, backup, and recovery. 3. Conventional database-backed applications follow. 4. Public and complex services follow after the pattern is proven. 5. Node-local game and GPU workloads migrate last. 6. The Foundry hosting platform proceeds as a separate product-development track after the base pattern is proven. ## Acceptance criteria - [x] A sanitized dataset and workload inventory is documented without credentials or sensitive file contents. - [x] Each inventoried workload has an ownership and migration classification. - [x] Required NFS access has been validated from designated cluster nodes. - [x] Dynamic NFS and iSCSI provisioning, permissions, expansion, persistence, and reclaim behavior have been validated with disposable clients under #5. - [x] Existing services remain operational while migration planning is completed. - [x] The migration priority and node-local storage exceptions are documented. ## Dependencies / blockers This issue blocks #6. The dynamic provisioning approach was selected and validated under #5; #6 must now formalize conventions using this inventory.

portegumi added the

storage

documentation

labels

2026-08-29 00:22:48 -05:00