Agent Diagnostic
- Investigated
crates/openshell-driver-kubernetes/src/driver.rs, specifically the sandbox_to_k8s_spec function
- Fetched the Sandbox CRD definition from https://github.com/kubernetes-sigs/agent-sandbox/blob/main/api/v1alpha1/sandbox_types.go
- Confirmed the CRD's
SandboxSpec only has: podTemplate, volumeClaimTemplates, lifecycle, replicas
- The driver was inserting
logLevel and environment at the .spec level of the Sandbox CR — fields that don't exist in the CRD schema
- Kubernetes silently ignores unknown fields on unstructured/dynamic objects, so these had zero effect
- The
environment map was already being passed into the pod container env via build_env_list, so that path worked
- The
log_level was only set at the dead CRD-level — it never reached the pod as an env var
Description
Actual behavior: Setting log_level on a sandbox spec when using the Kubernetes compute driver has no effect. The value is inserted as a logLevel field on the Sandbox CR's .spec, but the agent-sandbox CRD (agents.x-k8s.io/v1alpha1) has no such field — Kubernetes silently drops it. There is no way to control the log level of sandbox pods via the k8s driver.
Similarly, the environment map was redundantly inserted at the CR spec level (no effect), though it was separately and correctly passed to the pod container env.
Expected behavior: The log_level field should be propagated as an OPENSHELL_LOG_LEVEL environment variable on the sandbox pod's container spec, allowing operators to control sandbox log verbosity.
Reproduction Steps
- Create a sandbox with a non-default
log_level via the gRPC API using the Kubernetes driver
- Inspect the created Sandbox CR —
logLevel field is present but ignored by the CRD controller
- Inspect the resulting pod — no
OPENSHELL_LOG_LEVEL env var is set
Environment
- Component:
crates/openshell-driver-kubernetes
- CRD:
agents.x-k8s.io/v1alpha1 Sandbox (kubernetes-sigs/agent-sandbox)
Logs
N/A — silent failure (fields are accepted by the k8s API but have no semantic effect)
Agent Diagnostic
crates/openshell-driver-kubernetes/src/driver.rs, specifically thesandbox_to_k8s_specfunctionSandboxSpeconly has:podTemplate,volumeClaimTemplates,lifecycle,replicaslogLevelandenvironmentat the.speclevel of the Sandbox CR — fields that don't exist in the CRD schemaenvironmentmap was already being passed into the pod container env viabuild_env_list, so that path workedlog_levelwas only set at the dead CRD-level — it never reached the pod as an env varDescription
Actual behavior: Setting
log_levelon a sandbox spec when using the Kubernetes compute driver has no effect. The value is inserted as alogLevelfield on the Sandbox CR's.spec, but theagent-sandboxCRD (agents.x-k8s.io/v1alpha1) has no such field — Kubernetes silently drops it. There is no way to control the log level of sandbox pods via the k8s driver.Similarly, the
environmentmap was redundantly inserted at the CR spec level (no effect), though it was separately and correctly passed to the pod container env.Expected behavior: The
log_levelfield should be propagated as anOPENSHELL_LOG_LEVELenvironment variable on the sandbox pod's container spec, allowing operators to control sandbox log verbosity.Reproduction Steps
log_levelvia the gRPC API using the Kubernetes driverlogLevelfield is present but ignored by the CRD controllerOPENSHELL_LOG_LEVELenv var is setEnvironment
crates/openshell-driver-kubernetesagents.x-k8s.io/v1alpha1 Sandbox(kubernetes-sigs/agent-sandbox)Logs
N/A — silent failure (fields are accepted by the k8s API but have no semantic effect)