Docs: access-and-deploy PV section is incomplete — mount the PVC into the running test app and verify
Where
docs/getting-started/access-and-deploy.md → §4 "(Optional) A persistent volume".
Problem
The section creates a PersistentVolumeClaim (demo-data) but never mounts it into a pod. The default StorageClass uses WaitForFirstConsumer (see storage guide), so the PVC stays Pending until something consumes it. A reader following the guide verbatim therefore sees a PVC that never binds and no disk that ever does anything — the demo looks broken. The text even says "Bound once the disk is provisioned + a pod mounts it" and then omits the mount step, which is the whole point.
Fix
Extend §4 to actually mount the volume into the hello app created in §3 (the user's suggestion — tie it to the running test app rather than an orphan PVC), then verify it works end to end:
- Add the volume + volumeMount to the existing
helloDeployment (e.g.kubectl patch/kubectl setor a re-applied manifest that mountsdemo-dataat a path like/data). - Show the PVC flip
Pending→Boundonce the pod schedules (WaitForFirstConsumer). -
Write then read back a file on the mount (
kubectl exec … -- sh -c 'echo hi > /data/f && cat /data/f') so the reader sees the real disk working. - (Nice-to-have) demonstrate persistence across a pod restart/reschedule — delete the pod, confirm the file survives on the reattached disk.
Keep it "(Optional)" and gated on the CSI add-on being installed (link to the storage guide, which now covers the one-time CRS apply + the location-scoped-grant caveat that can 403 disk creation).
Acceptance
Following §4 verbatim yields a Bound PVC mounted into the running hello pod, with a verified read/write (and ideally survival across a restart) — so the getting-started walkthrough ends with persistent storage visibly working, not a Pending PVC.
Related: same "getting-started must actually work when followed" theme as #17 (closed) (the e2e gate would exercise this once storage is in scope) and #13 (closed)/#14 (closed)/#15 (closed).