feat: support mounting existing PVCs into OGO-managed sandboxes #61

Summary

OGO-managed sandboxes cannot currently mount pre-existing PVCs. This prevents use cases where sandboxes need to share storage with other workloads — for example, CI/CD pipeline steps that prepare a workspace before the agent runs and process results afterward, or shared dataset and model weight volumes across sandbox instances.

The upstream OpenShell Kubernetes driver recently added support for mounting existing PVCs into sandbox pods via driver_config.kubernetes.volumes and driver_config.kubernetes.containers.agent.volume_mounts (NVIDIA/OpenShell#2033, merged in NVIDIA/OpenShell#2034). This means the underlying sandbox API now supports it, but there is no documented or tested pattern for using this capability against an OGO-managed gateway, and no guidance on the deployment constraints it introduces.

Use cases

CI/CD pipeline with shared workspace: A pipeline orchestrator (e.g., Tekton, Argo Workflows) manages a workspace PVC across steps. Non-sandboxed steps clone a repo and prepare the workspace, a sandboxed step runs an AI agent against it, and a final non-sandboxed step pushes results. All steps mount the same PVC:

Step 1 (non-sandboxed): clone repo, validate inputs     →  writes to shared PVC
Step 2 (sandboxed):     AI agent works on the codebase   →  reads/writes shared PVC
Step 3 (non-sandboxed): push branch, create PR           →  reads from shared PVC

This eliminates file upload/download overhead between the orchestrator and the sandbox.

Shared data volumes: Multiple sandboxes or non-sandbox workloads mount a common ReadOnlyMany PVC containing datasets, model weights, or reference documentation. The PVC is managed independently from any single sandbox's lifecycle.

Configuration injection: Mounting ConfigMaps or Secrets into sandbox pods for environment-specific configuration that doesn't belong in the sandbox image or provider credentials.

Deployment constraints

Namespace alignment: The sandbox pod and the PVC must be in the same namespace. OGO's SandboxSpec.namespace controls where sandbox pods are created. Workloads that want to share PVCs with sandboxes must run in the same namespace. The recommended approach is one gateway per team with the sandbox namespace matching the workload namespace, rather than cross-namespace PVC access.

Authentication: Non-interactive workloads (CI steps, pipeline controllers) creating sandboxes against an OGO-managed gateway need a supported auth path. mTLS works today; workload identity auth is tracked in #48 and is a dependency for ServiceAccount-based callers.

Proposed scope

• Document the shared volume pattern: a guide showing how to create sandboxes that mount existing PVCs via driver_config, including namespace requirements, auth prerequisites, and RWO scheduling considerations.
• CI/CD integration example: a concrete example (e.g., Tekton Task template) demonstrating the multi-step shared-workspace pattern with sandboxed and non-sandboxed steps.
• Assess CRD changes: determine whether any SandboxSpec fields or new CRD-level configuration is needed to facilitate shared volumes, or whether the upstream driver_config passthrough is sufficient for all use cases.
• End-to-end validation: test the shared volume pattern against an OGO-managed gateway, covering sandbox creation with mounted PVCs, concurrent access, and cleanup.

Dependencies

• NVIDIA/OpenShell#2034 — upstream driver_config PVC mount support (merged 2026-07-10). Requires OpenShell >= v0.0.82. OGO's current default (imageTag: "0.0.92") already includes this.
• OGO Support OpenShell workspace membership for workload identities #48 — workspace membership for workload identities. Required for ServiceAccount-based callers (CI pipelines, controllers) that can't use interactive SSO.

Versions

• OGO: v0.2.2 and current main
• OpenShell: >= v0.0.82 (includes #2034 driver_config PVC mount support). OGO already defaults to 0.0.92.