Skip to content

feat(workspaces-test): the actor-level mount of an existing volume at a sub-path #469

Description

@teemow

Problem

agentlab workspaces-test --storage-only proves the NFS CSI driver, a read-write-many claim, two pods on their own session sub-paths with the mirrors read-only, and the controller endpoint refused without Substrate's certificate, but its last step, an actor mounting a session directory of the volume through ate-api-server, is a hard-coded skip (internal/lab/workspacestest.go:491: "skipped: the Substrate line carries no mount of an existing read-write-many volume at a sub-path yet"), with no detection of whether the line carries it.

The Substrate line carries it since v1.7.0-rc.1 (giantswarm/substrate#234, closes giantswarm/substrate#227): Volume.existing_volume marks a template volume each actor supplies, VolumeMount.sub_path and read_only shape its mounts, and CreateActor takes Actor.existing_volumes (name, CSI driver, volume handle, access mode READ_WRITE_MANY or READ_ONLY_MANY, the actor's sub_path). With the lab on that release the proof still skips the step, so the feature is not exercised end to end in the lab: the platform on v1.7.0-rc.1 (both OCIRepositories and HelmReleases, atelet, ate-api-server, the WorkerPool's ateom-gvisor:1.7.0-rc.1 workers) passed the storage proof and the golden boot, with the actor-level mount untested.

Proposed solution

Replace the skip with the step itself, on the volume the proof already seeded (mirrors/repo.git, sessions/):

  • An ActorTemplate declaring one existing_volume with two mounts: sessions read-write at the session path, mirrors read-only at the mirrors path (sub-paths relative to the actor's sub_path).
  • Two actors created through ate-api-server (as the ate-client ServiceAccount, in atespace kagent, the way the step's preamble already reaches it), each referencing the claim's PersistentVolume by driver nfs.csi.k8s.io and its volume handle, access mode READ_WRITE_MANY, sub_path sessions/a and sessions/b.
  • Assert: each actor sees its own session directory read-write and the mirrors read-only, a write into the mirrors is refused, nothing of the other actor's session is visible, pause and resume keep the content, deleting both actors leaves the PersistentVolume and the files, and a reference with an unknown driver or a missing handle is refused at create with the reason.
  • The run on a line without the feature (a Substrate below 1.7.0) reports the skip from ate-api-server's refusal of the field, not from a constant.

A machine whose agentlab checkout is behind main runs a binary newer than its source (the lab machine's clone was 9 commits behind while the proof ran from a current binary): the fixer builds from current main.

Acceptance criteria

  • agentlab workspaces-test --storage-only on a lab with Substrate >= 1.7.0-rc.1 runs the actor-level step: two actors on one NFS volume at their own sub-paths, the read-only mirrors refusing a write, isolation, pause/resume, delete leaving the volume, bad references refused at create
  • The same run on a Substrate without the field reports the skip with ate-api-server's reason
  • The step's output names the Substrate chart version it ran against

This issue was written by an agent.

Activity

  1. teemow commented on Oct 9, 2026

    @teemow
    MemberAuthor

    The step in #470 declares two existing volumes in the ActorTemplate rather than one with two mounts: session (read-write at /workspace) and mirrors (read-only at /mirrors), both supplied by each actor from the claim's one PersistentVolume handle, session read-write-many at sessions/a or sessions/b, mirrors read-only-many at mirrors. An actor's sub_path is the root its mounts of that volume are relative to, and a mount's sub_path may not contain .., so a single volume rooted at sessions/a cannot also reach mirrors/. Substrate's own existing-volumes e2e uses the same shape.

    This comment was written by an agent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    • Status
      Done ✅

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions