User Story
As an OpenShell API or SDK user targeting Kubernetes, I want Kubernetes-native resource settings to live in Kubernetes driver configuration, so that portable sandbox resources have one typed API and backend-specific settings are explicit.
Problem Statement
SandboxTemplate.resources is a public free-form Struct that now has mixed semantics. CPU and memory are being moved to typed portable resource requirements, while the remaining Kubernetes-native resource keys are translated through gateway platform config and consumed only by the Kubernetes driver. Docker and VM reject that translated config, and Podman/MXC do not consume it.
Impact / Why This Matters
Users cannot tell from the public template shape which resource fields are portable and which apply only to Kubernetes. The current field also leaves a legacy API surface with ambiguous validation and merge behavior. The workaround is to know the gateway translation details; that is not a stable SDK contract.
Proposed Design
Move Kubernetes-native container resources to the Kubernetes-specific driver configuration. Keep portable GPU, CPU, and memory under typed workload resource requirements. Deprecate and then remove SandboxTemplate.resources, providing a clear migration error and documentation for callers that use Kubernetes-native resources.
Acceptance Criteria
Alternatives Considered
Keep SandboxTemplate.resources as a platform-native escape hatch. This preserves a familiar Struct, but it leaves an ambiguous public API and a Kubernetes-only capability on the portable template surface.
Retain CPU and memory in SandboxTemplate.resources. This conflicts with #2838, which intentionally moves portable compute sizing to typed resource requirements.
Agent Investigation
Related to #2838. The gateway currently preserves non-CPU/non-memory entries from template.resources as resources_raw, and only the Kubernetes driver applies them to the workload container. This work belongs under #2565, the parent API-stabilization tracker.
User Story
As an OpenShell API or SDK user targeting Kubernetes, I want Kubernetes-native resource settings to live in Kubernetes driver configuration, so that portable sandbox resources have one typed API and backend-specific settings are explicit.
Problem Statement
SandboxTemplate.resourcesis a public free-form Struct that now has mixed semantics. CPU and memory are being moved to typed portable resource requirements, while the remaining Kubernetes-native resource keys are translated through gateway platform config and consumed only by the Kubernetes driver. Docker and VM reject that translated config, and Podman/MXC do not consume it.Impact / Why This Matters
Users cannot tell from the public template shape which resource fields are portable and which apply only to Kubernetes. The current field also leaves a legacy API surface with ambiguous validation and merge behavior. The workaround is to know the gateway translation details; that is not a stable SDK contract.
Proposed Design
Move Kubernetes-native container resources to the Kubernetes-specific driver configuration. Keep portable GPU, CPU, and memory under typed workload resource requirements. Deprecate and then remove
SandboxTemplate.resources, providing a clear migration error and documentation for callers that use Kubernetes-native resources.Acceptance Criteria
SandboxTemplate.resourcesreceive a clear migration error before the field is removed or reserved.Alternatives Considered
Keep
SandboxTemplate.resourcesas a platform-native escape hatch. This preserves a familiar Struct, but it leaves an ambiguous public API and a Kubernetes-only capability on the portable template surface.Retain CPU and memory in
SandboxTemplate.resources. This conflicts with #2838, which intentionally moves portable compute sizing to typed resource requirements.Agent Investigation
Related to #2838. The gateway currently preserves non-CPU/non-memory entries from
template.resourcesasresources_raw, and only the Kubernetes driver applies them to the workload container. This work belongs under #2565, the parent API-stabilization tracker.