Run anywhere: cloud and Kubernetes runners behind one abstraction; jobs that move issue #33 open andymccall opened this · 1 comment
andymccall set labels flow-next, feature ·
Design for the moving part (2026-10-25): docs/handover.md. Decided with Andy: no live migration of running microVMs. A Firecracker snapshot keeps its vCPU count (Firecracker cannot add vCPUs to a running VM), so moving a job from a small runner to a big one makes it no faster; it moves gigabytes of memory, needs the same architecture and CPU features, and cannot help when the runner simply disappears. Instead jobs move their progress: requeue with leases and a drain message (issue #76), checkpoint directories restored on another runner (issue #77), a faster runner hedging (issue #78), trust classes deciding whose work a job accepts (issue #79). This issue keeps the cloud and Kubernetes pools themselves (jetstream.md §9).
Andy (2026-10-02): jobs should run on GCP, AWS, Azure and Kubernetes in a next-gen way, abstract enough that where does not matter; e.g. a slow runner's job could move to another provider mid-job (idea).
Shape (to design, not built): an elastic runner that asks a provider (cloud VM API, or a K8s Job/pod with KVM nodes or the syscall tier) for capacity on demand and gives it back idle; the job's world already content-addressed (inputs as Oxygen states mounted through flow-casfs, outputs as blobs), so a job's scratch can live on a casfs-backed overlay; moving mid-job = checkpoint the microVM (Firecracker snapshots) with its overlay, ship to another runner, resume. Start: provider plug-in interface + a K8s and one cloud provider; then snapshot/resume.