Phase 3: Migrate PostgreSQL from bare metal to CloudNative PG #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Status: DECOMPOSED — see children below
This ticket has been split into 3 dispatchable children matching the rollback boundary.
Children
Why split
10 boxes = too broad for one subagent window. Splitting by rollback boundary lets step 1+2 fail safely while bare-metal remains authoritative.
Original goal (preserved)
Move Postgres data layer to k3s CNPG operator. Enables HA later.
Original acceptance (preserved)
Depends on
Close condition
Close this parent when devops#12 is verified complete and Forgejo + Umami are functional on CNPG.
Triage: Still pending — blocked on workers (#3) and Tailscale IPs (#9)
Phase 3 (Postgres → CNPG) depends on:
The cluster is live with system pods running (coredns, metrics-server, grafana, prometheus), so CNPG operator installation (
kubectl apply --server-side -f ...) could proceed on the control plane alone if desired. However, the Postgres migration script and safe cutover likely require the full cluster topology including the PV/local-path provisioner setup.Leaving open — pending Scott's decision on whether to start CNPG install before workers are ready.
BLOCKED — This ticket requires:
Available from this host: n97-mini with single-node k3s (control-plane only).
Cannot bootstrap workers or migrate databases without the target nodes being online.
Scott needs to power on and verify the worker hardware before this ticket can proceed.
❌ BLOCKED
Reason: Worker nodes offline — Phase 3 (Postgres migration) requires worker nodes on k3s first
This ticket was previously identified as blocked. It requires Scott's action or external infrastructure before dispatch can proceed. Once unblocked, the system will pick it up on the next dispatch cycle.
Action for Scott: Phase 3 (Postgres migration) requires worker nodes on k3s first
Subagent Progress Report (Cycle 4, 2026-05-30)
Status: Partially complete — reached tool-call limit before migration finish.
What was accomplished
cnpg-system. Operator pod running, CRDs present.homeschool,openbrain,pool_manager,postgres,style_prefs,umami. Users includeumami,style_prefs,openbrain_mcp.postgresql://umami@localhost/umami?host=/run/postgresql— confirmed migration target.services.postgresqlin config,database.type = "sqlite3"). Ticket assumption that Forgejo needs PG migration needs updating.n97-miniReady. Existing plainpostgresDeployment indatabasesnamespace must be retired.devopsrepo on disk orapps/postgres/cluster.yaml— these may not yet exist locally.Next steps
Clustermanifest and apply todatabasenamespace.postgres-usersSecret with credentials.pg_dumpall) and restore into CNPG primary.Re-unassigned by dispatch system — infrastructure task timed out so not immediately re-dispatched. Next cycle will assess.
Dispatch Cycle Update (2026-05-30 04:54 UTC)
Status: Subagent timed out after 600s without completing work.
What happened:
Action:
Note to next cycle: The prior cycle found CNPG operator already installed in
cnpg-system. Bare-metal PG verified with dbs: homeschool, openbrain, pool_manager, umami, style_prefs. Forgejo uses SQLite. Consider breaking this into smaller chunks (manifest creation vs migration vs NixOS rebuild).Dispatched to @agent-engineering at cycle start. WIP limit observed.
Dispatch cycle timeout after 600s during initial investigation. No edits applied. Will re-dispatch in a future cycle with a narrower scope.
Dispatch cycle: ticket previously timed out twice. Per no-blind-redispatch rule, deferred until split into smaller child issues or handled directly.
Subagent dispatched but timed out after 600s during CNPG Postgres migration validation and nixos-rebuild steps. Unassigned. Will retry in next cycle.
🔀 Decomposed into 3 children (2026-06-01, per Scott's "unblock what you can" directive)
This ticket had 10 checkboxes spanning cluster creation, data migration, app cutover, and nixos-rebuild. After 3 subagent timeouts, scope is too broad for one window.
Children created:
[devops#4.1]Create CNPG cluster + verify Ready condition[devops#4.2]Migrate data from bare-metal Postgres to CNPG cluster[devops#4.3]Cutover: Forgejo + Umami to CNPG, disable bare-metalWhy this works: Each step is independently reversible. Step 1 (cluster create) is observable. Step 2 (migrate) is testable without cutover. Step 3 (cutover) only runs after the prior two succeed — and only step 3 has irreversible consequences (disabling bare-metal PG). This separation matches the rollback boundary: if step 2 fails, bare-metal is still authoritative; if step 3 fails, you roll back via the dump file.
This parent is removed from
double_timeout(scope materially changed). Note: the dispatch-timeout-patterns doctrine says infrastructure tickets should never be sub-dispatched (useterminalor manual session). The children are still dispatchable but should be handled via focusedterminalsessions, notdelegate_task. Close this parent when devops#12 is verified complete.— Chief of Staff
Housekeeping close — decomposed into children
Per CoS dispatch cycle 2026-06-03, closing this parent. All Phase 3 work now lives in the children:
blocked— [devops#4.2] Migrate data from bare-metal Postgres to CNPG cluster (blocked on sscoble/devops#3 bootstrap-worker-nodes)Status: Step 1 of 3 shipped (CNPG cluster created and Ready). Steps 2 and 3 are blocked on infrastructure prerequisite (worker node bootstrap — sscoble/devops#3) and depend on each other.
Pattern: Same as sscoble/speckl#45 housekeeping close on 2026-06-02 (parent → child decomposition carried by the children's tickets). The parent ticket's body already documents the children inline.
This ticket is now archival; all forward progress happens in #10, #11, #12.