Design Kubernetes Job-backed warded runs as the Docker replacement path #1264

New issue

Open

opened 2026-07-14 09:59:56 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-14 09:59:56 +00:00

Member

Decision

Go, from coilysiren/inbox#211.

Use Kubernetes Jobs as the target substrate path for warded runs, and treat the longer-term direction as replacing Docker-backed engineer containers entirely with Kubernetes Job-backed execution.

Scope

Design the Ward substrate boundary needed to launch, observe, stop, reap, and collect logs from Kubernetes Jobs.
Map today's Docker/container assumptions to Kubernetes primitives: Job, Pod, PVC or workspace volume, Secrets/ServiceAccounts, logs, exit status, timeout, and cleanup.
Identify which behavior must remain in Ward's workflow kernel and which behavior belongs to cluster manifests or deploy/infra.
Produce a phased migration plan from Docker-backed warded runs to Kubernetes Job-backed runs.
Call out any host-broker behavior that disappears or changes when Docker is no longer the substrate.

Non-goals

Do not add Argo, Daytona, E2B, or another substrate in this slice.
Do not remove the Docker path until the Kubernetes path has parity for launch, logs, cleanup, and workflow outcome reporting.
Do not make this a generic substrate platform; keep the goal tied to Ward's agent-run lifecycle.

Parent: coilysiren/inbox#211.

## Decision Go, from coilysiren/inbox#211. Use Kubernetes Jobs as the target substrate path for warded runs, and treat the longer-term direction as replacing Docker-backed engineer containers entirely with Kubernetes Job-backed execution. ## Scope - Design the Ward substrate boundary needed to launch, observe, stop, reap, and collect logs from Kubernetes Jobs. - Map today's Docker/container assumptions to Kubernetes primitives: Job, Pod, PVC or workspace volume, Secrets/ServiceAccounts, logs, exit status, timeout, and cleanup. - Identify which behavior must remain in Ward's workflow kernel and which behavior belongs to cluster manifests or deploy/infra. - Produce a phased migration plan from Docker-backed `warded` runs to Kubernetes Job-backed runs. - Call out any host-broker behavior that disappears or changes when Docker is no longer the substrate. ## Non-goals - Do not add Argo, Daytona, E2B, or another substrate in this slice. - Do not remove the Docker path until the Kubernetes path has parity for launch, logs, cleanup, and workflow outcome reporting. - Do not make this a generic substrate platform; keep the goal tied to Ward's agent-run lifecycle. Parent: coilysiren/inbox#211.

coilyco-ops added the

consult

labels

2026-07-14 09:59:56 +00:00