Agent Diagnostic
Loaded the openshell-driver-kubernetes crate and traced the volume claim template lifecycle through sandbox_to_k8s_spec() and sandbox_template_to_k8s() in driver.rs.
Findings:
driver.rs:898-902: When the user provides volume_claim_templates via platform_config, user_has_vct = true and inject_workspace = false.
driver.rs:940-944: User VCTs are passed through to spec.volumeClaimTemplates on the Sandbox CR.
driver.rs:1129-1131: apply_workspace_persistence() is skipped entirely when inject_workspace is false — this is the only code path that adds PVC-backed volume mounts to the agent container.
driver.rs:1073-1082: The agent container spec only has hardcoded mounts for openshell-client-tls. No mechanism exists to mount user VCTs.
- The SAG controller creates PVCs and injects
corev1.Volume entries into the pod spec, but without a matching volumeMount the PVCs are unreachable.
No existing test covers the user-VCT-with-mount path — only workspace_persistence_skipped_when_inject_workspace_false (line 1912) which validates the absence of mounts.
Description
Actual behavior: When a user provides custom volume_claim_templates in the SandboxTemplate platform_config, the PVCs are created by the sig-agent-sandbox controller but no volumeMount entries are added to the agent container. The volumes exist in the pod spec but are never attached to any container.
Additionally, providing any custom VCT disables the default workspace persistence entirely — the /sandbox mount is lost with no way to restore it.
Expected behavior: User-provided VCTs should be mounted in the agent container at /sandbox (reusing the default workspace mount path). The seeding init container should be skipped for user VCTs since users are bringing their own storage.
Reproduction Steps
- Create a SandboxTemplate with custom
volume_claim_templates in platform_config
- Create a sandbox using that template
- Observe that PVCs are created in the cluster
- Exec into the agent container — no PVC is mounted; data written to
/sandbox is not persisted
Root Cause
apply_workspace_persistence() bundles two concerns into one all-or-nothing function:
- Adding the
volumeMount at /sandbox on the agent container
- Adding the seeding init container that copies image content into the PVC
When inject_workspace = false (user provided VCTs), both are skipped. The mount should still be applied for user VCTs; only the seeding init container should be skipped.
Proposed Fix
Split apply_workspace_persistence() so the volume mount and the init container are independent:
- Always mount user VCTs at
/sandbox on the agent container
- Only add the seeding init container when using the default workspace VCT (not user-provided)
Agent Diagnostic
Loaded the
openshell-driver-kubernetescrate and traced the volume claim template lifecycle throughsandbox_to_k8s_spec()andsandbox_template_to_k8s()indriver.rs.Findings:
driver.rs:898-902: When the user providesvolume_claim_templatesvia platform_config,user_has_vct = trueandinject_workspace = false.driver.rs:940-944: User VCTs are passed through tospec.volumeClaimTemplateson the Sandbox CR.driver.rs:1129-1131:apply_workspace_persistence()is skipped entirely wheninject_workspaceis false — this is the only code path that adds PVC-backed volume mounts to the agent container.driver.rs:1073-1082: The agent container spec only has hardcoded mounts foropenshell-client-tls. No mechanism exists to mount user VCTs.corev1.Volumeentries into the pod spec, but without a matchingvolumeMountthe PVCs are unreachable.No existing test covers the user-VCT-with-mount path — only
workspace_persistence_skipped_when_inject_workspace_false(line 1912) which validates the absence of mounts.Description
Actual behavior: When a user provides custom
volume_claim_templatesin the SandboxTemplateplatform_config, the PVCs are created by the sig-agent-sandbox controller but novolumeMountentries are added to the agent container. The volumes exist in the pod spec but are never attached to any container.Additionally, providing any custom VCT disables the default workspace persistence entirely — the
/sandboxmount is lost with no way to restore it.Expected behavior: User-provided VCTs should be mounted in the agent container at
/sandbox(reusing the default workspace mount path). The seeding init container should be skipped for user VCTs since users are bringing their own storage.Reproduction Steps
volume_claim_templatesinplatform_config/sandboxis not persistedRoot Cause
apply_workspace_persistence()bundles two concerns into one all-or-nothing function:volumeMountat/sandboxon the agent containerWhen
inject_workspace = false(user provided VCTs), both are skipped. The mount should still be applied for user VCTs; only the seeding init container should be skipped.Proposed Fix
Split
apply_workspace_persistence()so the volume mount and the init container are independent:/sandboxon the agent container