Repository navigation
runtime adapter: template and clone operations #847
Description
Parent: #834 (#833), step 5. Needs: #846, and #805's PR 3 (executions in the test adapter's VMs). Unblocks: stage 1's completion.
Goal. The in-repo test adapter implements every template and clone operation, through public APIs and its own framing, and runs the stage's scenarios as one suite.
Today (dev d04d9fb): runtime-adapter-host has launch, reattach, stop, probe and report (tests/runtime-adapter/src/bin/runtime-adapter-host.rs:125-255). #841 and #844 add the create and start paths that their own tests need.
The operations:
| Operation | Contract |
|---|---|
| Create, refresh | Select the admitted bundle, the profile, the capacities, the boot-online counts, the NIC class and the policy. Return the full key and generation only after the store commit. Never triggered by a restore. |
| List, inspect | The key, the generation, compatibility metadata, eligibility and its reason, state and leases, without loading VM state or hashing |
| Remove, retire | Stop new acquisitions first; report busy while leases remain; never move or delete a leased generation. remove retires, then deletes once the leases drain. |
| Start from a template | An explicit, eligible selection, plus the prepared image, scratch and settings. The outcomes: no template, expired or ineligible, request, host, template, or unresolved teardown. No capture, cold, rehash or format fallback. |
| Run from a template | The visible image preflight, then a managed clone's Start, one execution and teardown |
Stacked PRs. PR 2 builds on PR 1; each lands with its own tests.
PR 1 of 2: template operations. Needs #841's PR 3.
runtime-adapter-hostcommands for create, refresh, list, inspect and remove, as the table says.- The adapter chooses the store's location and eviction, as any adapter does.
- Tests: each operation's outcomes, including
removewith live leases.
PR 2 of 2: start and run from a template, and the stage's suite. Needs PR 1, #846, and #805's PR 3.
- Start and run commands, as the table says. Run's entrypoint and environment go through authenticated execution control, never captured tokens, and the execution runs in the clone's root, through runtime adapter: settle executions through cgroups and run them in a VM #805. No second root assembler.
- The adapter's README lists the operations and every clone scenario. The CI hook names each one.
- Tests: the stage's consolidated suite, in the adapter's CI hook on KVM, MSHV and WHP: every scenario of nvx-rs: capture preparation in the guest, and template mode in the test adapter's guest #840 to nvx-rs: activate a clone's root for GPT images and either upper, with its export, network settings and workload view #845 and nvx-rs: lower, capture and publish platform templates #841 to nvx-rs: exports, MAPS and network templates for clones #846, plus each operation's outcomes, and template
runwith one execution in the clone. A script-only proof doesn't count.
Done when: both PRs are merged, and stage 1's acceptance (#834) passes.
Activity
Integrate #846 PR 2 with #847 PR 2 for the stage's suite