diff --git a/docs/consultations/gemini-modpack-installer-followup-2026-04-15.md b/docs/consultations/gemini-modpack-installer-followup-2026-04-15.md index 5e26d46..ac6b695 100644 --- a/docs/consultations/gemini-modpack-installer-followup-2026-04-15.md +++ b/docs/consultations/gemini-modpack-installer-followup-2026-04-15.md @@ -196,3 +196,78 @@ Redis is a new infrastructure dependency for LuckPerms messaging service. Full consultation complete. Three rounds, all questions answered, provision.json validated. **Ready for:** Holly review → final spec → Code + +--- + +## Gemini's Response — Round 4: PostgreSQL Schema + pg-boss Queue (April 15, 2026) + +**Summary:** Complete database schema and job queue blueprint. Ready for Code phase after Holly review. + +### Part 1: PostgreSQL Schema + +#### Updates to server_config +```sql +ALTER TABLE server_config +ADD COLUMN modpack_provider VARCHAR(50), +ADD COLUMN modpack_id VARCHAR(100), +ADD COLUMN current_version_id VARCHAR(100), +ADD COLUMN is_version_locked BOOLEAN DEFAULT FALSE, +ADD COLUMN locked_version_id VARCHAR(100) DEFAULT NULL, +ADD COLUMN lock_reason TEXT DEFAULT NULL, +ADD COLUMN spawn_verified BOOLEAN DEFAULT FALSE, +ADD COLUMN ram_allocation_mb INT NOT NULL DEFAULT 8192, +ADD COLUMN ram_ceiling_mb INT NOT NULL DEFAULT 16384, +ADD COLUMN hibernation_status VARCHAR(50) DEFAULT 'active'; +``` + +#### New: install_history table +```sql +CREATE TABLE install_history ( + id UUID PRIMARY KEY DEFAULT gen_random_uuid(), + server_id UUID REFERENCES server_config(id) ON DELETE CASCADE, + pterodactyl_server_id VARCHAR(100), + job_type VARCHAR(50) NOT NULL, + target_version_id VARCHAR(100) NOT NULL, + triggered_by VARCHAR(100) NOT NULL, + status VARCHAR(50) NOT NULL, + started_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), + completed_at TIMESTAMP WITH TIME ZONE, + duration_seconds INT, + mods_injected INT DEFAULT 0, + log_output JSONB DEFAULT '{}' +); + +CREATE INDEX idx_install_history_recent_failures +ON install_history(server_id, status, started_at); +``` + +### Part 2: pg-boss Queue Architecture + +Three queues: +- `modpack-installs` — concurrency 2 (heavy file I/O) +- `maintenance-tasks` — concurrency 5 (ghost updates, hibernation) +- `fast-sync` — concurrency 20 (LuckPerms pings, Discord alerts) + +### Worker Execution Flow +1. Job picked up → install_history status = `running` +2. Pre-flight: node RAM/disk check, Java version mapping → correct egg +3. Pterodactyl server provisioned +4. Download pack → scrub client mods against Firefrost Reject List +5. Standard stack injection from NextCloud +6. Inject provision.json + Holly-Bot mod +7. Stream to Pterodactyl via SFTP/Wings +8. Cloudflare DNS + Discord channels created +9. Power on → spawn_verified = false (enters Holly's queue) → install_history = success → staff Discord ping + +### Gemini's Question +> "Does this schema and queue architecture pass the smell test, or do we need to adjust how we're handling ghost_update staging in the DB?" + +**Answer:** It passes. ghost_update staging can live as a job_type in install_history ('ghost_update') with status tracking through the queue. No additional DB columns needed — the staging folder on disk is the state, the DB just tracks the job. + +--- + +## FULL CONSULTATION COMPLETE ✅ + +Four rounds. Architecture locked. Schema defined. Queue designed. provision.json validated. + +**Status:** Awaiting Holly review → Holly names the bot → Final spec → Code