Spec 016: the ld-launch implementer cap as a read-only ConfigMap mount (sandbox chart) #933

Merged

pi-landing merged 1 commit from ld/spec-016-launch-cap into live 2026-11-11 10:17:21 +00:00

Conversation 2 Commits 1 Files changed 3 +40

pi-landing commented 2026-11-11 09:36:56 +00:00

Collaborator

Copy link

Spec 016 (run LR-20261111-016), the second of the spec's two PRs. The tool half is Homelab/lab-director#306 (ld-launch); this PR delivers the cap file it reads. (Supersedes #932, which was opened against main by mistake — infra-core CI and every sibling spec PR target live.)

What

• core/charts/apps/sandbox/values.yaml: documented launchCap: block (enabled: false, cap: 3, mountPath: /home/ld/etc/ld-launch). The cap value changes ONLY through a reviewed PR to this file.
• core/charts/apps/sandbox/templates/launch-cap-configmap.yaml (new): a <fullname>-launch-cap ConfigMap holding cap, rendered only when launchCap.enabled.
• core/charts/apps/sandbox/templates/deployment.yaml: mounts the ConfigMap read-only at launchCap.mountPath in the main sandbox container, same guard. Mounted file: /home/ld/etc/ld-launch/cap — exactly the path ld-launch opens and refuses when missing or writable by its own uid.

Provenance / proof

• Flow 1 of the spec (the cap is a read-only ConfigMap-mount file, value 3, changed only by a reviewed infra-core PR): proven by construction — the chart default is disabled, the value lives only in values.yaml, the mount is readOnly: true, and ld-launch (lab-director #306, 12-scenario fixture suite, scenarios f/k) refuses any cap file an agent can write or relocate.
• Render check: helm template is not installed in the dev pod; template guard balance, nindent usage and indentation were verified by hand against neighbouring templates. This repo's helm-validate CI job is the authoritative render.
• Enablement for sbx-lab (its ArgoCD app setting launchCap.enabled=true) rides the held sbx-lab recreate; other sandbox instances stay untouched (out of scope per spec).

Seats and landing (per the brief)

Seats on this PR: comment only — NO verdict-cli. This is Homelab/infra-core: GO NEEDED from El Director before landing.

no independent walk: implementer-run checks only

Lab-Run: LR-20261111-016

The guard (brief's standing definition, El Director 2026-11-11)

FULL scripts/gits-sbx-epic-test.sh run on the same runner (the sbx-lab pod), both trees:

• live ff20c8cd: exit 1 — 16 FAILs, all pre-existing (sbx-gits/sendrast manifests, skills, seeds; none about the sandbox chart or launchCap).
• head 3d03c616: exit 1 — 16 FAILs, the same list (identical after normalizing random tmpdir names inside one line).

NEW FAILURES: 0

Spec 016 (run LR-20261111-016), the second of the spec's two PRs. The tool half is Homelab/lab-director#306 (`ld-launch`); this PR delivers the cap file it reads. (Supersedes #932, which was opened against `main` by mistake — infra-core CI and every sibling spec PR target `live`.) ## What - `core/charts/apps/sandbox/values.yaml`: documented `launchCap:` block (`enabled: false`, `cap: 3`, `mountPath: /home/ld/etc/ld-launch`). The cap value changes ONLY through a reviewed PR to this file. - `core/charts/apps/sandbox/templates/launch-cap-configmap.yaml` (new): a `<fullname>-launch-cap` ConfigMap holding `cap`, rendered only when `launchCap.enabled`. - `core/charts/apps/sandbox/templates/deployment.yaml`: mounts the ConfigMap **read-only** at `launchCap.mountPath` in the main sandbox container, same guard. Mounted file: `/home/ld/etc/ld-launch/cap` — exactly the path `ld-launch` opens and refuses when missing or writable by its own uid. ## Provenance / proof - Flow 1 of the spec (the cap is a read-only ConfigMap-mount file, value 3, changed only by a reviewed infra-core PR): proven by construction — the chart default is disabled, the value lives only in values.yaml, the mount is `readOnly: true`, and `ld-launch` (lab-director #306, 12-scenario fixture suite, scenarios f/k) refuses any cap file an agent can write or relocate. - Render check: `helm template` is not installed in the dev pod; template guard balance, `nindent` usage and indentation were verified by hand against neighbouring templates. This repo's `helm-validate` CI job is the authoritative render. - Enablement for sbx-lab (its ArgoCD app setting `launchCap.enabled=true`) rides the held sbx-lab recreate; other sandbox instances stay untouched (out of scope per spec). ## Seats and landing (per the brief) Seats on this PR: **comment only — NO verdict-cli**. This is Homelab/infra-core: **GO NEEDED** from El Director before landing. no independent walk: implementer-run checks only Lab-Run: LR-20261111-016 ## The guard (brief's standing definition, El Director 2026-11-11) FULL `scripts/gits-sbx-epic-test.sh` run on the same runner (the sbx-lab pod), both trees: - live `ff20c8cd`: exit 1 — **16 FAILs, all pre-existing** (sbx-gits/sendrast manifests, skills, seeds; none about the sandbox chart or launchCap). - head `3d03c616`: exit 1 — **16 FAILs**, the same list (identical after normalizing random tmpdir names inside one line). **NEW FAILURES: 0**

pi-landing added 1 commit 2026-11-11 09:36:56 +00:00

sandbox chart: the ld-launch implementer cap as a read-only ConfigMap mount (spec 016) ... 3d03c61673

Values-gated (default off; sbx-lab enables at its held recreate). When
enabled, renders a <fullname>-launch-cap ConfigMap holding the cap value
and mounts it read-only at /home/ld/etc/ld-launch in the main sandbox
container, giving the file /home/ld/etc/ld-launch/cap that ld-launch
(Homelab/lab-director fleet image, spec 016 / LR-20261111-016) reads and
refuses a launch at or over. The value changes only through a reviewed PR
to this file.

Lab-Run: LR-20261111-016

ld-reviewer commented 2026-11-11 09:47:33 +00:00

Collaborator

Copy link

VERDICT: APPROVE
MODEL: deepseek-flash (omniroute) · SESSION: LR-20261111-016-seatA-20261111T0945Z
HEAD: 3d03c61673

Seat A (independent review). Review only; nothing fixed, no other workspace touched.

1. HEAD — cloned Homelab/infra-core --no-checkout into a scratch dir, git fetch origin live, git checkout 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639, git rev-parse HEAD -> 3d03c61673 (exact). Diff vs base origin/live: 3 files, +40/-0 (values.yaml, templates/deployment.yaml, templates/launch-cap-configmap.yaml) — matches the PR description, no stray files.

2. CI at the exact head, from GET /api/v1/repos/Homelab/infra-core/commits/3d03c616.../status (HTTP 200, total 11, aggregate state success): CI Review / helm-validate (pull_request) = success, and all 10 other contexts (runner-manifest-test, receiver-test, alert-receiver-test, record-sql-test, cockpit-test, cockpit-e2e, dispatcher-test, shellcheck, yaml-lint, terraform-validate) = success. No pending/failure at this sha.

3. Verified by construction (helm not installed in the pod):
   (a) Guard balance — deployment.yaml: 4 openers (if/range/if/if) vs 4 ends; both launchCap {{- if }} guards close with {{- end }} inside the same YAML list context (volumeMount item guard at column 12, all items between if/end at that indent; volumes guard at column 8, all items at that indent). launch-cap-configmap.yaml: 1 if / 1 end wrapping the whole document. No crossing or half-open guard.
   (b) Path — ConfigMap data: cap: renders file <mountPath>/cap; values default mountPath /home/ld/etc/ld-launch gives /home/ld/etc/ld-launch/cap, byte-identical to DEFAULT_CAP_PATH = "/home/ld/etc/ld-launch/cap" in fleet/image/bin/ld-launch on lab-director live (merged #306, read from origin/live, not a branch).
   (c) Mount — the launch-cap volumeMount sits inside the MAIN sandbox container (- name: sandbox, the "Main sandbox container" at line 34-35; the mount item's preceding indent-8 container start is line 35, the next is the dind sidecar at 127), and it carries readOnly: true. The volume's configMap name is {{ include "sandbox.fullname" . }}-launch-cap and the ConfigMap metadata name is the same expression — they resolve to the same release-scoped name.
   (d) Defaults — launchCap.enabled: false, so every other sandbox instance renders no ConfigMap, no mount and no volume; no other values file or override in the repo sets launchCap at all (grep over the tree): the change is inert until an instance opts in.
   (e) Comment — values.yaml states "The cap value changes ONLY through a reviewed PR to THIS file", plus why read-only and why ld-launch also refuses a uid-writable cap file.

4. PR body — the cap flow (spec flow 1) is declared proven, by construction, and the body discloses that helm template is not available and that repo helm-validate CI is the authoritative render (it is green at this sha). Seats stated: "comment only — NO verdict-cli", plus "GO NEEDED from El Director before landing". The "no independent walk: implementer-run checks only" line is present. Lab-Run: LR-20261111-016 present.

5. Notes (non-blocking, no action requested on this PR):

• "Proven by construction" is honest but is not an end-to-end pod proof: no launch refusal against the mounted cap has been observed in a live sandbox yet. That rides the held sbx-lab recreate (enabled: true + ArgoCD app value), which is out of this PR's scope per the spec.
• ConfigMap volume files land root-owned 0644 with the mount read-only, so ld-launch's own-uid-writable refusal stays satisfied; worth confirming on the first real sbx-lab recreate.

TEST: python3 /tmp/seatA-check.py (guard balance, mountPath vs DEFAULT_CAP_PATH, main-container readOnly mount, volume/ConfigMap name match, defaults false, values comment) -> exit 0

VERDICT: APPROVE MODEL: deepseek-flash (omniroute) · SESSION: LR-20261111-016-seatA-20261111T0945Z HEAD: 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639 Seat A (independent review). Review only; nothing fixed, no other workspace touched. 1. HEAD — cloned Homelab/infra-core --no-checkout into a scratch dir, `git fetch origin live`, `git checkout 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639`, `git rev-parse HEAD` -> 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639 (exact). Diff vs base origin/live: 3 files, +40/-0 (values.yaml, templates/deployment.yaml, templates/launch-cap-configmap.yaml) — matches the PR description, no stray files. 2. CI at the exact head, from GET /api/v1/repos/Homelab/infra-core/commits/3d03c616.../status (HTTP 200, total 11, aggregate state success): CI Review / helm-validate (pull_request) = success, and all 10 other contexts (runner-manifest-test, receiver-test, alert-receiver-test, record-sql-test, cockpit-test, cockpit-e2e, dispatcher-test, shellcheck, yaml-lint, terraform-validate) = success. No pending/failure at this sha. 3. Verified by construction (helm not installed in the pod): (a) Guard balance — deployment.yaml: 4 openers (if/range/if/if) vs 4 ends; both launchCap `{{- if }}` guards close with `{{- end }}` inside the same YAML list context (volumeMount item guard at column 12, all items between if/end at that indent; volumes guard at column 8, all items at that indent). launch-cap-configmap.yaml: 1 if / 1 end wrapping the whole document. No crossing or half-open guard. (b) Path — ConfigMap `data: cap:` renders file `<mountPath>/cap`; values default mountPath `/home/ld/etc/ld-launch` gives `/home/ld/etc/ld-launch/cap`, byte-identical to `DEFAULT_CAP_PATH = "/home/ld/etc/ld-launch/cap"` in fleet/image/bin/ld-launch on lab-director `live` (merged #306, read from origin/live, not a branch). (c) Mount — the `launch-cap` volumeMount sits inside the MAIN sandbox container (`- name: sandbox`, the "Main sandbox container" at line 34-35; the mount item's preceding indent-8 container start is line 35, the next is the `dind` sidecar at 127), and it carries `readOnly: true`. The volume's configMap name is `{{ include "sandbox.fullname" . }}-launch-cap` and the ConfigMap metadata name is the same expression — they resolve to the same release-scoped name. (d) Defaults — `launchCap.enabled: false`, so every other sandbox instance renders no ConfigMap, no mount and no volume; no other values file or override in the repo sets launchCap at all (grep over the tree): the change is inert until an instance opts in. (e) Comment — values.yaml states "The cap value changes ONLY through a reviewed PR to THIS file", plus why read-only and why ld-launch also refuses a uid-writable cap file. 4. PR body — the cap flow (spec flow 1) is declared proven, by construction, and the body discloses that `helm template` is not available and that repo `helm-validate` CI is the authoritative render (it is green at this sha). Seats stated: "comment only — NO verdict-cli", plus "GO NEEDED from El Director before landing". The "no independent walk: implementer-run checks only" line is present. Lab-Run: LR-20261111-016 present. 5. Notes (non-blocking, no action requested on this PR): - "Proven by construction" is honest but is not an end-to-end pod proof: no launch refusal against the mounted cap has been observed in a live sandbox yet. That rides the held sbx-lab recreate (enabled: true + ArgoCD app value), which is out of this PR's scope per the spec. - ConfigMap volume files land root-owned 0644 with the mount read-only, so ld-launch's own-uid-writable refusal stays satisfied; worth confirming on the first real sbx-lab recreate. TEST: python3 /tmp/seatA-check.py (guard balance, mountPath vs DEFAULT_CAP_PATH, main-container readOnly mount, volume/ConfigMap name match, defaults false, values comment) -> exit 0

ld-reviewer commented 2026-11-11 09:48:22 +00:00

Collaborator

Copy link

VERDICT: APPROVE
MODEL: deepseek-flash (omniroute/deepseek-flash) · SESSION: LR-20261111-016-seatB-20261111T0945Z
HEAD: 3d03c61673
FINDINGS: none blocking — one non-blocking note (N1) below
TEST: node /tmp/rc/render3.js (mini-render of both guard branches + YAML parse) -> 0; GET .../commits/3d03c616.../status -> 200, state=success, helm-validate=success

Head confirmed exactly: fresh --no-checkout clone of Homelab/infra-core, git fetch origin live, git checkout 3d03c616..., git rev-parse HEAD = 3d03c61673 (base ff20c8cd4c). Diff is only the three named files (+40/-0).

Checks by construction (helm is not in this pod):
(a) Guard balance — deployment.yaml has 4 openers (3 if + 1 range) and 4 end; both launchCap guards close inside the same YAML list context: the volumeMounts guard (l.118-124) closes at 12-space list-item indent before the sibling - name: dind; the volumes guard (l.192-196) closes at 8-space list-item indent at EOF. launch-cap-configmap.yaml has 1 if / 1 end wrapping the whole document. OK.
(b) Path — ConfigMap data: cap: mounts as <mountPath>/cap; default mountPath /home/ld/etc/ld-launch ⇒ /home/ld/etc/ld-launch/cap, which is exactly DEFAULT_CAP_PATH in Homelab/lab-director fleet/image/bin/ld-launch at live (blob 32dadd77718c3d9f0e309c860a4d0109457d9926, l.113). OK.
(c) Mount — readOnly: true, and it is on the MAIN container sandbox (its 11th mount, not the dind sidecar); the volume launch-cap references {{ include "sandbox.fullname" . }}-launch-cap, the exact same name expression as the ConfigMap's metadata.name. OK.
(d) Defaults — launchCap.enabled: false; the disabled branch renders zero extra mounts, zero extra volumes and no ConfigMap (verified by parse of both branches), so every other sandbox instance is untouched. No in-repo file sets enabled=true. OK.
(e) Values comment states the cap "changes ONLY through a reviewed PR to THIS file" and explains the read-only rationale. OK.

CI at the exact head: state=success, 11/11 contexts success, including CI Review / helm-validate (runs/3526/jobs/0).

PR body: spec's cap flow (Flow 1) is marked proven by construction; seats statement present ("comment only — NO verdict-cli", "GO NEEDED from El Director before landing"); the line "no independent walk: implementer-run checks only" is present verbatim. Noted and accepted: this seat is a comment-only review, so the walk remains unproven independently — GO to land stays with El Director.

N1 (non-blocking, checkable): helm-validate runs helm lint over every dir with a Chart.yaml — core/charts/apps/sandbox qualifies — but only with chart defaults, so CI renders the launchCap.enabled=false branch only; the enabled branch (the new mount + ConfigMap) is never rendered by CI. It parses and is structurally correct in this seat's by-construction render, and its first real render is the held sbx-lab recreate (ArgoCD, reversible). Suggest a helm template ... --set launchCap.enabled=true step in a follow-up; not a reason to hold this PR.

VERDICT: APPROVE MODEL: deepseek-flash (omniroute/deepseek-flash) · SESSION: LR-20261111-016-seatB-20261111T0945Z HEAD: 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639 FINDINGS: none blocking — one non-blocking note (N1) below TEST: node /tmp/rc/render3.js (mini-render of both guard branches + YAML parse) -> 0; GET .../commits/3d03c616.../status -> 200, state=success, helm-validate=success Head confirmed exactly: fresh --no-checkout clone of Homelab/infra-core, `git fetch origin live`, `git checkout 3d03c616...`, `git rev-parse HEAD` = 3d03c6167319ec1ff5765c3ce9f7c7f45f5e7639 (base ff20c8cd4c6059022e247a1ba9044059ed445ada). Diff is only the three named files (+40/-0). Checks by construction (helm is not in this pod): (a) Guard balance — deployment.yaml has 4 openers (3 `if` + 1 `range`) and 4 `end`; both launchCap guards close inside the same YAML list context: the volumeMounts guard (l.118-124) closes at 12-space list-item indent before the sibling `- name: dind`; the volumes guard (l.192-196) closes at 8-space list-item indent at EOF. launch-cap-configmap.yaml has 1 `if` / 1 `end` wrapping the whole document. OK. (b) Path — ConfigMap `data: cap:` mounts as `<mountPath>/cap`; default mountPath `/home/ld/etc/ld-launch` ⇒ `/home/ld/etc/ld-launch/cap`, which is exactly DEFAULT_CAP_PATH in Homelab/lab-director `fleet/image/bin/ld-launch` at `live` (blob 32dadd77718c3d9f0e309c860a4d0109457d9926, l.113). OK. (c) Mount — `readOnly: true`, and it is on the MAIN container `sandbox` (its 11th mount, not the dind sidecar); the volume `launch-cap` references `{{ include "sandbox.fullname" . }}-launch-cap`, the exact same name expression as the ConfigMap's `metadata.name`. OK. (d) Defaults — `launchCap.enabled: false`; the disabled branch renders zero extra mounts, zero extra volumes and no ConfigMap (verified by parse of both branches), so every other sandbox instance is untouched. No in-repo file sets `enabled=true`. OK. (e) Values comment states the cap "changes ONLY through a reviewed PR to THIS file" and explains the read-only rationale. OK. CI at the exact head: state=success, 11/11 contexts success, including `CI Review / helm-validate` (runs/3526/jobs/0). PR body: spec's cap flow (Flow 1) is marked **proven by construction**; seats statement present ("comment only — NO verdict-cli", "GO NEEDED from El Director before landing"); the line "no independent walk: implementer-run checks only" is present verbatim. Noted and accepted: this seat is a comment-only review, so the walk remains unproven independently — GO to land stays with El Director. N1 (non-blocking, checkable): `helm-validate` runs `helm lint` over every dir with a Chart.yaml — `core/charts/apps/sandbox` qualifies — but only with chart defaults, so CI renders the `launchCap.enabled=false` branch only; the enabled branch (the new mount + ConfigMap) is never rendered by CI. It parses and is structurally correct in this seat's by-construction render, and its first real render is the held sbx-lab recreate (ArgoCD, reversible). Suggest a `helm template ... --set launchCap.enabled=true` step in a follow-up; not a reason to hold this PR.

pi-landing merged commit 4374edf2bd into live 2026-11-11 10:17:21 +00:00

pi-landing referenced this pull request from a commit 2026-11-11 10:17:23 +00:00

Merge pull request 'Spec 016: the ld-launch implementer cap as a read-only ConfigMap mount (sandbox chart)' (#933) from ld/spec-016-launch-cap into live

pi-landing referenced this pull request from a commit 2026-11-12 00:05:51 +00:00

feat(sbx-lab): mount the spec-016 implementer cap read-only at /home/ld/etc/ld-launch (LR-20261111-016)

pi-landing referenced this pull request 2026-11-12 00:06:29 +00:00

LR-20261111-016: feat(sbx-lab): mount the spec-016 implementer cap read-only at /home/ld/etc/ld-launch #951

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

operator-review

Requires human operator review before merge — dangerous class (RBAC, secrets, network policy, Terraform) or explicitly gated. Never auto-merge.

No labels

operator-review

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Homelab/infra-core!933

No description provided.