Migrate TradeGumi as the first proof-of-concept application workload #12

New issue

Closed

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

portegumi commented

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

Collaborator

Description

Use TradeGumi as the first end-to-end application migration litmus test. It exercises application deployment, persistent state, internal services, configuration, routing, health checks, and rollback without selecting a core infrastructure service or hardware-bound workload as the first candidate.

Scope

Apply the approved migration runbook to the existing TradeGumi deployment.
Inventory application, PostgreSQL, Redis, storage, routing, and credential requirements.
Keep the current deployment available until the Kubernetes workload is validated and an explicit cutover occurs.
Validate persistence, service connectivity, health, routing, observability, backup, and rollback.
Feed lessons learned back into the migration runbook.

Acceptance criteria

Storage and secret-handling choices follow repository conventions.
The Kubernetes deployment passes functional and persistence checks before routing changes.
The existing deployment remains available for rollback through the agreed observation period.
Cutover and rollback procedures are tested or safely rehearsed.
The migration runbook is updated with lessons from the proof of concept.

Dependencies / blockers

Blocked by cluster bootstrap, networking, storage conventions, and the migration runbook. Pi-hole, MinIO, Authentik, ComfyUI, and game servers remain excluded as first-migration candidates.

## Description Use TradeGumi as the first end-to-end application migration litmus test. It exercises application deployment, persistent state, internal services, configuration, routing, health checks, and rollback without selecting a core infrastructure service or hardware-bound workload as the first candidate. ## Scope - Apply the approved migration runbook to the existing TradeGumi deployment. - Inventory application, PostgreSQL, Redis, storage, routing, and credential requirements. - Keep the current deployment available until the Kubernetes workload is validated and an explicit cutover occurs. - Validate persistence, service connectivity, health, routing, observability, backup, and rollback. - Feed lessons learned back into the migration runbook. ## Acceptance criteria - [ ] Storage and secret-handling choices follow repository conventions. - [ ] The Kubernetes deployment passes functional and persistence checks before routing changes. - [ ] The existing deployment remains available for rollback through the agreed observation period. - [ ] Cutover and rollback procedures are tested or safely rehearsed. - [ ] The migration runbook is updated with lessons from the proof of concept. ## Dependencies / blockers Blocked by cluster bootstrap, networking, storage conventions, and the migration runbook. Pi-hole, MinIO, Authentik, ComfyUI, and game servers remain excluded as first-migration candidates.

portegumi added the

storage

app-migration

labels

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