randomparity / randomparity/kdive
Implement adopt: the BYO Provisioner, preconditions, and runtime binding
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
Part of #1814
## Problem
`Provisioner.provision` still returns #1817's fail-closed stub. This entry makes it *adopt*: reach
the declared host, prove it is what the operator claimed, record the facts, and mint a usable
System. Adopt is the whole difference between this provider and every existing one — nothing is
created, so provisioning is entirely an act of verification.
Two `ProviderRuntime` fields also have defaults that are **actively wrong** for BYO and must be set
here, because both are per-resource facts adopt resolves:
- **`binding` is mandatory.** BYO serves many declared hosts. Without a rebind hook, `for_resource`
returns the runtime unchanged and every op resolves against one arbitrary host's config.
- **`platform_root_cmdline` must be `None`.** It defaults to `"root=/dev/vda"`, which would be
injected into a real machine's kernel cmdline, overriding the root device its own bootloader
already knows.
A third gap is an admission hole: **`resolve_accel()` fail-*opens*** when a resource advertises no
guest arches. Without publishing `arch` into `Resource.capabilities`, a ppc64le profile is happily
admitted onto an x86 BYO host and fails late, at install, after an allocation was granted and
billed.
## Evidence
- `src/kdive/providers/ports/lifecycle.py:88` — `Provisioner.provision`, keyed on an
already-minted System id.
- `src/kdive/providers/core/runtime.py:165` — `for_resource` returns `self` when `binding is None`.
- `src/kdive/providers/remote_libvirt/composition.py:391` — the multi-host precedent sets
`binding=ResourceBindingCapabilities(rebind_for_resource=...)` (ADR-0187).
- `src/kdive/providers/core/runtime.py:143` — `platform_root_cmdline: str | None = "root=/dev/vda"`;
`src/kdive/providers/remote_libvirt/composition.py:390` overrides it to `None` because the
in-guest bootloader owns the root device (ADR-0183).
- `src/kdive/services/systems/validation.py:50` — `resolve_accel` returns `None` (skipping the
check) when the resource advertises no guest arches: "That fail-open case skips the check and
records no accel."
- `src/kdive/providers/remote_libvirt/connection/endpoint_preflight.py` — the preflight precedent.
## Expected outcome
- `Provisioner.provision` implemented as adopt: SSH reachable, OOB endpoint reachable and
credential valid, arch matches the declaration, bootloader flavor detected, kdump/fadump
readiness checked, baseline kernel present. Facts recorded on the System row.
- Preconditions factored into a **shared module**, because #1814's doctor entry reuses them rather
than duplicating the checks.
- `binding=ResourceBindingCapabilities(...)` and `platform_root_cmdline=None` wired.
- The declared `arch` published into `Resource.capabilities` so admission rejects a mismatched
profile at `systems.create` — not at install. This is #1814 success criterion 6.
- A failed precondition raises a specific `ErrorCategory` naming which check failed and what to do
about it, per the fail-fast rule.
Blocked by #1819
Blocked by #1818
Contributor guide
Research direction
Start with src/kdive/providers/ports/lifecycle.py:88, then read the runtime fields in src/kdive/providers/core/runtime.py and the preflight precedent at src/kdive/providers/remote_libvirt/connection/endpoint_preflight.py. Review resolve_accel in src/kdive/services/systems/validation.py. Done means adopt verifies and records the listed facts, shares its preconditions, wires the runtime binding and root setting, and publishes the declared arch for admission.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100