randomparity / randomparity/kdive
Add the BYO control plane: SysRq force-crash and OOB power
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
Part of #1814
## Problem
Two control operations complete the BYO spine, and both need the pieces built above them:
- **Power** — `Controller.power()` is a required port. On an adopted host the only reliable answer
is the OOB driver, since a wedged kernel will not honor an in-band request.
- **Deliberate crash** — force-crash is what KDIVE exists to do. On real hardware it is magic SysRq
injected through the serial console, which is why this depends on the console plane rather than
the driver alone.
Deliberately crashing a physical machine is more consequential than crashing a VM: there is no
hypervisor to reset it, and recovery runs through the same OOB path. The existing destructive-op
gate applies unchanged and must not be weakened.
## Evidence
- `src/kdive/providers/ports/lifecycle.py:251` — `Controller.power()`, whose docstring already
anticipates `TRANSPORT_FAILURE` "when a remote provider's control channel cannot connect".
- `src/kdive/security/authz/gate.py` — `force_crash` requires the allocation project's RBAC role
**and** an explicit profile opt-in (ADR-0130 removed the old `capability_scope` factor). Reused
as-is; this entry adds no new gate.
- `src/kdive/providers/core/runtime.py:82` — `supports_diagnostic_sysrq`, "Fail-closed: a provider
that cannot inject SysRq into its guests' consoles leaves it False and the tool refuses with
`capability_unsupported`" (ADR-0285/0427).
- `src/kdive/providers/core/runtime.py:87` — `supports_crash_watch` (ADR-0367/0427), whose value
here depends on the console-ownership answer from #1815.
- #1808 — both wrapped control planes refuse `interrupt`, which is why the OOB drivers in this epic
talk to the service processor directly.
- Related prior work under epic #1760: #1779 (fail-closed x86 hardware crash mechanisms) and #1780
(authenticated SysRq crash control). See #1814's overlap table.
## Expected outcome
- `Controller.power()` delegating on/off/reset to the per-host OOB driver, with a specific
`ErrorCategory` when the OOB channel is unreachable.
- `force_crash` via magic SysRq through the console channel, behind the **existing** destructive-op
gate — same RBAC role and profile opt-in, no new bypass.
- `supports_diagnostic_sysrq = True`; `supports_crash_watch` set per #1815's console-ownership
decision, fail-closed if that decision leaves the console exclusively owned during a session.
- Concurrency: power and crash serialize per-System via the existing advisory locks; a crash racing
a teardown must not interleave.
- Adversarial tests for the race paths, consistent with `tests/adversarial/`.
Blocked by #1826
Contributor guide
Research direction
This is blocked by #1826 and depends on the console-ownership decision in #1815. Start with src/kdive/providers/ports/lifecycle.py:251, src/kdive/providers/core/runtime.py, src/kdive/security/authz/gate.py, and the existing advisory-lock code; then read tests/adversarial/. Done means OOB power operations and console SysRq crash control honor the existing gate, serialize per System, fail closed, and cover the race paths.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, infrastructure, operating-systems, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 28/100