randomparity / randomparity/kdive
Add the HMC out-of-band driver for PowerVM LPARs
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
Part of #1814
## Problem
A PowerVM LPAR has no BMC. Its out-of-band control plane is the HMC, which is a different shape
from a per-host service processor: one HMC fronts many managed systems, each holding many
partitions, so a host is identified by `(managed_system, lpar_name)` rather than by an endpoint of
its own.
That difference is why this driver lands early — it is the one most likely to reveal that the
#1818 port shape encodes a per-host BMC assumption. Finding that out here is cheap; finding it out
during the POWER live proof is not.
This driver is also the reason the epic exists in its current form: #1808 established that the
wrapped control planes cannot express what KDIVE needs from an LPAR.
## Evidence
- #1808 — MAAS's `hmc` power driver (`src/provisioningserver/drivers/power/hmc.py`) is paramiko
SSH over `chsysstate`/`lssyscfg`, declares `can_set_boot_order = False` and `can_probe = False`,
hardcodes `--bootstring network-all`, and raises `NotImplementedError` for reset. Beaker's `lpar`
power script delegates to `fence_lpar`, offering `on|off|reboot|status` and **explicitly
rejecting `interrupt`**. A driver that cannot interrupt cannot serve a force-crash plane.
- #1808 also records that the HMC exposes two automation surfaces — an SSH restricted shell and a
REST API (XML/Atom "UOM" model, async Job pattern) — and that the ecosystem standardized on the
former. Which one this driver uses is a decision for #1815.
- `src/kdive/providers/byo_host/oob/` — the port from #1818.
- #1817's `[byo_host.oob]` block already carries `managed_system` / `lpar_name` for `kind = "hmc"`.
- Related prior work under epic #1760: #1776 (HMC virtual-terminal artifacts) covers the same vterm
surface from the MAAS-premise side — see #1814's overlap table; do not work both in parallel.
## Expected outcome
- An HMC driver satisfying the #1818 port, with LPAR identity as `(managed_system, lpar_name)`.
- Power control including the partition states an LPAR actually has, not just on/off.
- vterm console attach.
- **Pinned SSH host-key verification** if the SSH surface is chosen — trust-on-first-use is not
acceptable for a credential this privileged.
- If the port needs revision to accommodate the broker model, that revision lands here and #1818's
Redfish driver is updated with it — better now than after three planes depend on the shape.
- Unit/contract tests against recorded HMC transcripts; no live HMC required to merge.
Blocked by #1818
Contributor guide
Research direction
Start with the OOB port in src/kdive/providers/byo_host/oob/ and the HMC evidence in src/provisioningserver/drivers/power/hmc.py, then review #1815 and the existing managed_system/lpar_name configuration from #1817. Resolve whether the port supports the HMC broker model before implementing power states and vterm attach. Done means the HMC driver satisfies the port, uses pinned SSH host-key verification if applicable, and has unit or contract tests from recorded HMC transcripts without requiring a live HMC.
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
- 25/100