test: minimal aleph.compose/1 V-PROGRAM flow on the pre-release network

[odesenfans]

Stacked on od/vprogram-validation (#35, green as of run 32368297653 with the full 2026-08-20 component refresh). Adds the docker-compose leg:

• fixtures: the aleph.compose/1 runtime bundle (2026.08.20 build, 297 MB, fetched from mainnet IPFS by CID, sha256-pinned) and its manifest template
• conftest: vprogram_compose_runtime_hash uploads both to the testnet per-run (native storage; the CCN config's 4 GiB max_file_size covers the bundle)
• test_vprogram_compose.py: vprogram create --compose with a single traefik/whoami service (network_mode host, --port 8080), waits for TEE placement, then asserts an attested / call returns the container's whoami dump

Requires aleph-cli 0.17.0-rc10 (vprogram create --compose, aleph-rs#344) and the compose runtime flavor from aleph-vm#1132.

[foxpatch-aleph]

Well-structured PR adding the aleph.compose/1 V-PROGRAM flow with sha256-pinned fixtures, a clean conftest fixture following the established two-step manifest patching pattern, and a focused end-to-end test. The CI workflow changes (IPv6 pool override, gRPC socket, rust supervisor impl, expanded diagnostics) are all well-justified with thorough comments. No correctness bugs or security issues found. A few minor stale comments and the absence of per-test V-PROGRAM cleanup are non-blocking observations consistent with the existing V-PROGRAM test suite.

.github/workflows/pr-tests.yml (line 301): Comment says "from the vprogram-fixtures release" but scripts/vprogram-artifacts.sh (lines 12-14) documents that the fib workload moved to mainnet storage, not the GitHub prerelease. Consider updating this comment to match the script's current behavior.

tests/test_vprogram_compose.py (line 37): No V-PROGRAM cleanup (e.g. vprogram delete) after the test, unlike test_programs.py which calls program delete in a finally block. This is consistent with test_vprograms.py, and tee-reset.sh wipes state post-run, but worth noting that leftover V-PROGRAMs hold TEE resources until the reset step.

scripts/crn-up.sh (line 75): read_vm_version() uses a direct dict key access m['components']['aleph-vm']['version'] which would KeyError if the manifesto only has branch. This is safe today because the branch check at line 328 short-circuits, but it's a latent fragility — consider using .get('version', '') for symmetry with read_vm_branch's .get('branch', '') pattern.

[foxpatch-aleph]

Well-structured PR adding the compose/1 V-PROGRAM validation leg with thorough documentation, sha256-pinned fixtures, robust retry logic that correctly distinguishes transient failures from attestation failures, and a fail-closed test verifying that wrong measurements produce no response body. The CI workflow improvements (IPv6 pool override, gRPC split, controller unit cleanup, --since log collection, network diagnostics) are well-motivated and cite specific run numbers for design decisions. Minor cosmetic and robustness nits noted but none blocking.

.github/workflows/pr-tests.yml (line 301): Comment says "from the vprogram-fixtures release" but vprogram-artifacts.sh now fetches the fib workload from mainnet storage instead of the GitHub prerelease. Consider updating to match the script's own header comment.

.github/workflows/pr-tests.yml (line 401): The block reads tee-network.txt mid-generation (while the { ... } > tee-network.txt redirect is still open) to extract uplink and tap interface names. This works because the ndppd status and ip addr outputs are written earlier in the block, but it's fragile — a future reordering of the echo blocks would silently break the tcpdump capture. Consider extracting these into shell variables earlier in the block before the redirect, or noting the ordering dependency.

tests/test_vprogram_compose.py (line 99): When the only retryable condition is stack_starting (502 body) and transient_transport never fires, curl_probe stays None and the timeout error reports "unverified curl probe: HTTP None". The 502 body is included via body[:500] so diagnostics are present, but capturing a curl probe on the first stack_starting too (not just transient_transport) would give a more actionable contrast in the timeout message.

.github/workflows/pr-tests.yml (line 275): The IPv6 prefix 2001:bc8:702:32d::/64 is hardcoded in the workflow. Not a secret, but if the Scaleway server's flexible IP allocation changes this will silently break V-PROGRAM IPv6 reachability tests. Consider adding a comment noting this is the Scaleway flexible-IP /64 and must match the server's attached prefix.

[foxpatch-aleph]

This PR adds the docker-compose V-PROGRAM test leg alongside the existing exec V-PROGRAM flow, with well-documented infrastructure changes (gRPC split, IPv6 pool override, controller cleanup, expanded diagnostics). The test logic correctly handles the compose-specific startup race (transport failures + 502 bodies during podman load/compose up) with appropriate retry loops and diagnostic probes. Fixture downloads are sha256-pinned and verified. The temporary TCB floor workaround is clearly documented with a removal condition. No correctness bugs or security issues found. Minor diagnostic gaps (curl_probe not captured on 502-only paths, hardcoded IPv6 pool) are non-blocking.

tests/test_vprogram_compose.py (line 112): The curl_probe is only captured when transient_transport is true (transport failure), not when stack_starting is true (502 body). If the stack only ever returns 502s and never has a transport failure, the error message at line 124 will show unverified curl probe: HTTP None. Consider capturing the curl probe on the 502 path as well, so the diagnostic is always populated regardless of which transient signal fires first.

.github/workflows/pr-tests.yml (line 277): The STATIC_CRN_IPV6_POOL=2001:bc8:702:32d::/64 is hardcoded in the workflow and is specific to the Scaleway Elastic Metal flexible-IP allocation. If the TEE server is ever moved or re-provisioned with a different IP range, this will silently break IPv6 reachability for V-PROGRAMs with no obvious error. Consider extracting this to a repository variable or secret (like vars.TEE_IPV6_POOL) so it's visible in the repo settings and easier to update.

.github/workflows/pr-tests.yml (line 403): The grep on lines 403-404 reads tee-network.txt while the surrounding { ... } > tee-network.txt block is still writing to it. This works because shell > truncates the file at open time and content written earlier in the block (lines 362-386) is already flushed, but it's fragile — a reader could see a partially-written line if buffering changes. Not a bug today, but worth a comment noting the self-read dependency.

[foxpatch-aleph]

Well-structured PR adding the compose V-PROGRAM flow with thorough comments and solid retry logic. The gRPC socket env var is applied to all CRNs (including Python-daemon DO CRNs) — worth confirming the Python daemon ignores it. The compose test lacks a fail-closed measurement assertion and IPv6 check present in the exec test. The tee-network.txt self-reading diagnostics are fragile but guarded. No blocking issues found.

scripts/crn-up.sh (line 363): ALEPH_VM_SUPERVISOR_GRPC_SOCKET is in the common supervisor.env block, applying to ALL CRNs. But ALEPH_VM_SUPERVISOR_IMPL=rust (line 434) is only set for confidential CRNs — DO CRNs stay on the Python daemon. The comment says "the daemon binds the socket" but the Python daemon may not know how to handle this env var. If the Python daemon ignores unknown env vars this is safe, but it would be cleaner to move this into the confidential-only block (line 431-435) or gate it on the supervisor impl, to match the comment's implication that this is for the two-process Rust split.

tests/test_vprogram_compose.py (line 100): curl_probe is only set when transient_transport failures occur (line 112). If all failures are stack_starting (502 "upstream unreachable"), curl_probe stays None and the deadline error message shows "HTTP None", reducing diagnostic value. Consider also capturing a curl probe on the first stack_starting failure.

tests/test_vprogram_compose.py (line 131): The compose test lacks a fail-closed assertion (wrong expected measurement must abort without printing a body) that test_vprograms.py:162-174 includes. Since the compose flow also pins SEV-SNP measurements, a fail-closed test would confirm the compose measurement pinning works end to end.

.github/workflows/pr-tests.yml (line 403): The uplink/tap interface extraction greps tee-network.txt while the { ... } > tee-network.txt block is still writing to it. The grep patterns may not match the actual output: ^proxy [a-z0-9]+ expects ndppd.conf-style lines, and iface vmtap[0-9]+ doesn't match ip addr output format (which uses N: vmtap0: not iface vmtap0). The if [ -n "$uplink" ] guard prevents breakage but the dual tcpdump capture may never execute.

tests/test_vprograms.py (line 174): Neither test_vprograms.py nor test_vprogram_compose.py include V-PROGRAM cleanup (analogous to program delete in test_programs.py:143). This is acceptable since the testnet is ephemeral and tee-reset.sh wipes VM state, but it diverges from the existing cleanup convention.

[foxpatch-aleph]

Well-structured PR adding the docker-compose V-PROGRAM leg with sha256-pinned fixtures, proper retry loops for transient startup failures, and thorough CI diagnostics. The test logic in test_vprogram_compose.py correctly handles the compose-specific startup race (502 + transport errors as not-ready signals) and reuses the exec test's attestation primitives. The CRN configuration changes (gRPC socket, rust supervisor, IPv6 pool override) are well-justified with clear comments. The tee-reset controller cleanup fixes a real journal-flooding problem. Non-blocking issues found are in the diagnostics-only CI step and a pre-existing timeout pattern in the upload retry helper.

.github/workflows/pr-tests.yml (line 404): The tap variable will always be empty: grep -oE 'iface vmtap[0-9]+' looks for iface vmtapN in tee-network.txt, but ip addr (line 365) outputs interfaces as 2: vmtap0: — the word iface only appears in ip link output. This silently disables the dual-capture diagnostics block at line 405. Consider grepping for the ip addr format instead, e.g. grep -oE 'vmtap[0-9]+:' | head -1 | tr -d ':'.

tests/conftest.py (line 346): _upload_with_balance_retry does not pass a timeout to the underlying aleph_cli subprocess call. The timeout parameter only gates the balance-retry loop, not the individual upload. With the 297 MB compose bundle (timeout=600), a hung network connection would block indefinitely instead of being caught by the deadline. Consider passing timeout= to the aleph_cli call (e.g. a per-attempt timeout of 300s) so network hangs also surface.

.github/workflows/pr-tests.yml (line 403): The uplink extraction regex ^proxy [a-z0-9]+ matches the ndppd.conf proxy <iface> { line, but only captures interface names matching [a-z0-9]+ — names with other chars (e.g. enp3s0 has no non-matching chars but ens0 also works; however an interface like br-abc123 would fail). Low impact since this is diagnostics-only and guarded by the if [ -n "$uplink" ] check, but worth widening to ^proxy \S+ for robustness.

[foxpatch-aleph]

Well-structured PR adding the aleph.compose/1 V-PROGRAM flow with thorough documentation of the complex TEE/SEV-SNP infrastructure. The test logic, fixture handling, and CI integration are sound. The main issues are non-blocking: a race condition in the CI network diagnostics where uplink/tap variables are grepped from a file still being written by the same shell redirect (silently skipping the dual-capture diagnostic), and the compose test's curl_probe not being captured for the stack_starting failure mode (producing a confusing 'HTTP None' in the error message).

.github/workflows/pr-tests.yml (line 403): The uplink and tap variables are extracted from tee-network.txt via grep, but the entire { ... } block's output is redirected to tee-network.txt on line 420 (} > tee-network.txt 2>&1). Since the shell hasn't flushed/closed the file yet when these greps run, the file content is either empty or incomplete at this point, so uplink and tap will almost always be empty. The dual-capture tcpdump diagnostic is silently skipped as a result. Consider writing the initial diagnostics to a temp file first, then grepping from that, or restructure to capture the interface names inline (e.g. from the $SSH \"ip addr\" output directly via a variable) before the redirect.

tests/test_vprogram_compose.py (line 112): curl_probe is only set when transient_transport is true, but the compose test also has a stack_starting transient condition (rc=0 with 'upstream unreachable' in body). If only stack_starting failures occur before the deadline, curl_probe remains None and the AssertionError reports 'unverified curl probe: HTTP None', which is unhelpful for debugging. Consider also capturing curl_probe when stack_starting is true, e.g. move the curl probe capture outside the if transient_transport guard to cover both transient cases.

tests/test_vprogram_compose.py (line 131): The exec V-PROGRAM test (test_vprograms.py) includes a fail-closed assertion that a wrong expected measurement aborts the call without printing a response body. The compose test lacks this coverage. While the fail-closed path is the same CLI codepath, adding a similar assertion here would guard against compose-specific regressions in the attestation gate.

[foxpatch-aleph]

Well-structured PR adding the compose V-PROGRAM e2e test on top of the existing exec V-PROGRAM validation. The new fixtures, conftest session fixtures, test files, and CI diagnostics are all correctly implemented with thorough documentation of non-obvious decisions (Scaleway IPv6 egress, tagged image-archive workaround, TCB floor relaxation). The retry loops properly distinguish transient startup failures from real attestation failures. The fail-closed measurement test in test_vprograms.py is a valuable security assertion. No correctness bugs or security issues found.

tests/test_vprograms.py (line 122): json.loads(health.stdout) assumes the health endpoint always returns valid JSON when rc==0. If the attest agent ever returns a non-JSON 200 body (e.g. during a partial startup), this raises JSONDecodeError instead of a clean assertion failure. The compose test handles this more defensively with "Hostname:" in body before any parsing. Consider wrapping in a try/except or checking content-type first, though this is non-blocking since rc==0 with non-JSON is itself a bug worth surfacing.

tests/test_vprogram_compose.py (line 111): The string match "upstream unreachable" in body couples the test to the attest agent's 502 response body text. If that string changes in a future compose runtime build, the retry loop would stop recognizing the not-ready-yet signal and the test would fail immediately on the first 502 instead of waiting for the stack to come up. Consider also checking the HTTP status code (if available via the CLI output) for a more stable signal.

.github/workflows/pr-tests.yml (line 403): Inside the { ... } > tee-network.txt block, grep reads tee-network.txt from disk to extract $uplink and $tap. The file is still being written to by the block's stdout redirection at this point. This works in practice because bash flushes prior lines before reaching the grep, but it's fragile — a buffered I/O implementation could miss the ip addr output. Since this is diagnostics-only (runs with if: always() and everything has || true), this is non-blocking.

manifesto.yml (line 63): Switching aleph-vm from a pinned version (1.13.0) to branch: dev means CI runs track the latest dev branch tip. This is appropriate for a testnet, but any breakage on aleph-vm dev will block all PRs until dev is fixed or this pin is reverted. Worth keeping in mind for CI stability.

[foxpatch-aleph]

Well-structured PR adding the aleph.compose/1 V-PROGRAM end-to-end test with thorough retry logic, good diagnostic coverage, and sha256-pinned fixtures. The test code is correct for the happy and transient-failure paths. Two issues worth noting: (1) the TEE network diagnostics step in the workflow reads tee-network.txt while it's still being written by the enclosing redirect block, and the uplink interface extraction pattern likely won't match the ip -6 neigh output, so the tcpdump dual-capture diagnostic will silently never run; (2) the compose test lacks a fail-closed assertion (wrong measurement pin) that the exec test includes, leaving a coverage gap for the compose attestation path.

.github/workflows/pr-tests.yml (line 403): The grep -oE '^proxy [a-z0-9]+' tee-network.txt reads tee-network.txt while it is still being written by the enclosing { ... } > tee-network.txt 2>&1 block (line 420). The file is opened with O_WRONLY|O_CREAT|O_TRUNC, so data written so far is visible, but the ^proxy [a-z0-9]+ pattern expects ip -6 neigh show proxy output to start with proxy <iface>, which may not match the actual format (typically proxy <iface> ndp <addr>). If uplink is empty, the entire tcpdump dual-capture block (lines 405-418) is skipped, silently dropping a key diagnostic. Consider extracting the uplink from ip -6 route show default output instead, or restructuring so the diagnostic data is written to a temp file that grep can reliably read.

.github/workflows/pr-tests.yml (line 424): The DNAT rule probing loop appends to tee-network.txt (line 425: >> tee-network.txt) while also grepping from it (line 424: grep -E "dnat.*:8443" tee-network.txt). Since the { } > tee-network.txt block has closed by this point, the grep reads the complete file, but the appended echo "attestation DNAT rule: $rule" >> tee-network.txt on line 425 could theoretically add new lines matching the grep pattern if the rule text itself contains "dnat.*:8443" — causing the while loop to process its own appended output. In practice the appended line starts with "attestation DNAT rule:" not "dnat", so this is safe, but it's fragile.

tests/test_vprogram_compose.py (line 112): curl_probe is only captured when transient_transport is true, not when stack_starting (502 body) is the failure mode. If the deadline expires with only stack-starting failures, the error message reports curl_probe as None. Consider also capturing the unverified curl probe when stack_starting is true, so the diagnostic is populated in the 502-only scenario.

tests/test_vprogram_compose.py (line 131): Missing fail-closed assertion. test_vprograms.py verifies that a wrong --expected-measurement causes the call to fail with no stdout (lines 162-174). The compose test should include the same assertion to verify the compose attestation path also fail-closes on a measurement mismatch.

[foxpatch-aleph]

Well-structured PR adding the docker-compose V-PROGRAM test flow with comprehensive CI diagnostics. The test logic, fixture management, and CI workflow changes are sound and follow existing patterns. The retry loops correctly distinguish transient startup failures from genuine errors, and the attestation verification path is well-tested (including the fail-closed case). A few minor issues in the network diagnostics grep patterns mean the dual-tcpdump capture will likely always be skipped, and the curl_probe diagnostic isn't captured during 502 startup windows. Neither affects test correctness.

.github/workflows/pr-tests.yml (line 403): The grep pattern ^proxy [a-z0-9]+ won't match ip -6 neigh show proxy output, which has lines like 2001:bc8:702:32d:: dev enp1s0 proxy (proxy at end, not start). Consider grep -oE 'dev [a-z0-9]+ .* proxy' or parse the dev field directly. Same issue on line 404: iface vmtap[0-9]+ won't match ip addr output format (3: vmtap0: <BROADCAST...>); consider [0-9]+: vmtap[0-9]+ or vmtap[0-9]+:. Both patterns being empty means the dual tcpdump capture block is always skipped, so the diagnostic data it was designed to collect is never gathered.

tests/test_vprogram_compose.py (line 112): The curl_probe is only captured when transient_transport is True. If the stack is still starting (502 "upstream unreachable" responses with rc=0), curl_probe stays None and the eventual error message reports HTTP None. Consider also capturing the probe when stack_starting is True — a 502 from the unverified curl confirms the proxy is reachable and the stack genuinely isn't ready, while a non-502 would indicate a different issue.

tests/conftest.py (line 346): _upload_with_balance_retry calls aleph_cli(...) without a timeout= argument, so subprocess.run gets timeout=None. The timeout parameter (e.g. 600 for the 297 MB compose bundle) only bounds the retry loop between attempts. If a single upload hangs, the function blocks indefinitely. Consider passing a per-attempt timeout to aleph_cli (e.g. timeout=300) so a hung upload is interrupted and the retry deadline actually applies.

.github/workflows/pr-tests.yml (line 166): cryptsetup-bin is installed on the CCN droplet, but confidential-artifacts.sh checks for cryptsetup on the TEE server (line 126), not the CCN. If there's another reason it's needed on the CCN, a brief comment would help; otherwise this may be unnecessary.