Parent Issue

Tracked by datum-cloud/enhancements#682 (Launch Workload Compute Service — "UFOs")

Summary

The compute service has no defined user-facing policy model for workload placement. Customers need a way to express where their workloads should run (which PoP locations, how many instances per location, spread vs. pack behavior) and the platform needs rules for what happens when a preferred location is unavailable. This is distinct from the federated control plane integration work in compute#85, which addresses the scheduling mechanics — this issue defines the policy surface that customers interact with.

Goals

• Define the API surface for expressing placement intent: location targeting (city-code, region), minimum and maximum instances per location, and spread constraints
• Define platform behavior when a preferred location is full or unavailable: fail hard, spill to next-best, or queue
• Define how placement policy interacts with quota — can a user target a location where they have no quota headroom?
• Document the placement policy model for customer-facing documentation

Non-Goals

• Implementing the scheduling mechanics in the federated control plane (tracked in compute#85)
• PoP capacity planning or deciding which PoPs offer compute

Open Questions

• What is the minimum placement expression at launch — single city code, or do we need multi-region spread on day one?
• Should placement constraints be on Workload, WorkloadDeployment, or both?
• What is the fallback behavior when no location satisfies the placement constraints?