randomparity / randomparity/kdive

Add the HMC out-of-band driver for PowerVM LPARs

Open
#1,822 0 comments 0 reactions 0 assignees View on GitHub
area:control-retrieve area:security effort:L priority:P1 provider:powervm status:blocked type:feature
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.