Repository navigation
srv3 WebUI-KVM virtual-media install, FROM SCRATCH: FIRST understand repo requirements (DESIGN.md, extdeps conventions, no handwritten/embedded js or shell, Playwright modeled in extdeps), produce a design for review, THEN implement. Prior approaches (hand-written .mjs, embedded-JS-emit) were reject - #5773
Merged
Merged
Conversation
…l mechanism srv3's OpenBMC 2.07 exposes virtual media ONLY via the legacy WebUI KVM (OpenBMC web-UI NBD over wss), NOT over Redfish/DMTF InsertMedia (404). The on-main solve therefore resolved srv3 to PxeHttpInstall — wrong, since PXE cannot cross the Tailscale overlay (needs BIOS net-stack + same-L2). Per DESIGN §3 (single authority; the OpenBMC web-UI mechanism is a DIFFERENT mechanism than DMTF Redfish VirtualMedia, not a nickname for it): - extdeps/bmc/capability: add a DISTINCT CapabilityWebuiVirtualMedia variant (kept separate from CapabilityVirtualMedia, the Redfish surface) and ground openbmc_2_07_00_capabilities to include it (srv3 live-probe confirms the web-UI KVM media path works). - gunbc/os_install_mechanism: add the WebuiVirtualMediaInstall arm; solve prefers Redfish VirtualMediaInstall (automatable standard) first, then WebuiVirtualMediaInstall, then FirmwareUpdateThenVirtualMedia, then PXE. srv3 now falls out of the grounded solve to WebuiVirtualMediaInstall. Witness green-by-execution (8/8 PASS via claim_executor) + discriminating RED control (dropping the capability flips srv3's two grounding tests to FAIL): - redfish_vm_preferred_over_webui (both caps -> Redfish, proves ordering) - webui_vm_capable_row_solves_webui (WebUI-only -> WebuiVirtualMediaInstall) - vm_capable_firmware_row_flips_to_update_path uses an update-only current row (srv3's row now carries WebUI VM, so the old test premise moved). The install-WORKFLOW over browser ops is HELD pending the operator's runner-origin decision (see docs/plans/srv3-webui-kvm-virtual-media.md §5); this PR is pure modeling, zero JS. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…al term, not a client nickname) CapabilityWebuiVirtualMedia / WebuiVirtualMediaInstall were named after one CLIENT (the WebUI browser). Per DESIGN §3 (single authority; cite the upstream's real name, not a coined nickname), the actual BMC capability is OpenBMC's nbd-proxy virtual media (upstream "proxy mode": browser/JS NBD server over a secure websocket carrying NBD) — distinct from DMTF Redfish InsertMedia (CapabilityVirtualMedia). The browser is just one client of that protocol; openbmc/jsnbd ships a non-browser reference (the nbd-proxy binary). Rename only — solve precedence (Redfish-VM > nbd-proxy-VM > firmware-update > PXE) and the 8/8 witness logic are unchanged: CapabilityWebuiVirtualMedia -> CapabilityNbdProxyVirtualMedia WebuiVirtualMediaInstall -> NbdProxyVirtualMediaInstall (+ matching test-fn / local-var names). srv3 still falls out to NbdProxyVirtualMediaInstall as a consequence of the grounded solve. This keeps the client-named nickname OFF main entirely (not cement-then-churn). The formal openbmc/jsnbd ExternalAuthority citation homes with the Layer-1 transport shape in the B design (extdeps/bmc/webui), not the capability taxonomy. Witness 8/8 green-by-execution via claim_executor. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…3 read-only probe Rewrite the srv3 virtual-media design from the rejected browser/Playwright path to architecture B: the WebUI KVM "attach media" is sugar over OpenBMC's documented nbd-proxy protocol (NBD carried in a secure WebSocket; BMC is the NBD client, we are the NBD server). The honest realization is a direct wss+NBD client in the Rust seed — a transport realization like ureq/sh, NOT UI automation. No browser, no JS. Adds: - §1 the protocol grounded from openbmc/jsnbd (nbd-proxy / nbd.js) + the NBD fixed-newstyle handshake + docs/designs/virtual-media.md. - §2 read-only srv3 probe findings: Redfish VirtualMedia 404 under BOTH Systems and Managers => InsertMedia AND legacy HTTPS/CIFS share-mount are OUT (answers parent's disambiguation; Tailscale-reachability for that path is moot). New doubt: nbd ws route 404s on non-upgrade GET + no static WebUI + KVM-video-only => nbd-proxy may not be compiled into this 2.07.00 build; settling it needs an operator-gated ws-upgrade dry-run. - §3 the §3 interface/transport/policy split for NbdProxyServe. - §6 two sign-off gates before any seed code: (1) operator ws-upgrade dry-run confirming nbd-proxy is present, (2) acceptance of a seed-resident wss+NBD client as the realization origin. Capability/dispatch modeling (8/8 witness) stays done in #5773; seed client deferred. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…p ungrounded NbdProxy VM capability)
Review (claude-opus-4-7, REQUEST_CHANGES) correctly caught a §5 fail-open: the
openbmc_2_07_00_capabilities cited row asserted CapabilityNbdProxyVirtualMedia for
srv3, but the design doc itself flags that surface as UNSETTLED — /nbd/0 404s on a
non-upgrade GET (indistinguishable from absent), and settlement is gated on the §6
operator ws-upgrade dry-run. Asserting the capability before the dry-run dispatches
srv3 to NbdProxyVirtualMediaInstall on an ungrounded fact.
Fix — leave the cited row at exactly what the read-only probe grounded:
- drop CapabilityNbdProxyVirtualMedia from openbmc_2_07_00_capabilities (back to
PowerControl/BootSourceOverride/AccountManagement/FirmwareUpdate — the 200-confirmed
Redfish surfaces; KVM video != virtual media).
- srv3 now HONESTLY solves to PxeHttpInstall today (FirmwareUpdate present, catalog
has no VM-capable firmware), not NbdProxyVirtualMediaInstall.
- witness: srv3_capabilities_are_grounded now asserts NbdProxyVirtualMedia == false;
srv3_install_mechanism_is_nbd_proxy_vm_today -> srv3_install_mechanism_is_pxe_until_dry_run.
Kept (reviewer: "the dispatch arm and discriminating RED rows are fine to land now"):
the NbdProxyVirtualMediaInstall enum arm + solve precedence, and the synthetic-row
proofs nbd_proxy_vm_capable_row_solves / redfish_vm_preferred_over_nbd_proxy — the arm
is proven on a GROUNDED synthetic row, not on srv3's ungrounded one.
Flipping srv3's row to CapabilityNbdProxyVirtualMedia is deferred to the PR that lands
the §6 dry-run confirmation receipt. Design doc §5 updated to match. Witness 8/8 green
by execution via claim_executor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…p was BACKWARDS (shipped false status) My prior "drift fix" was the wrong direction and un-landed correct status (§5 ships-false-status trap). Ground truth (parent neat-boar-71 verified by reading both files on origin/main): - the committed .md said Phase A "[LANDED #5756]" = CORRECT - the .dag authority (host_effect_orchestration.dag) says "[now, parallel]" = STALE (the authority itself was regressed, likely by #5764 grounding a pre-landed draft). main_wet regenerated the .md FROM the stale .dag, propagating the regression INTO the .md and reverting the accurate "[LANDED #5756]" back to "[now, parallel]". My differential control (committed == origin/main) only proved the drift was not introduced by this PR's 4 model files — it did NOT establish which side was correct. I wrongly assumed authority==truth; here the authority was the stale side. Fix: restore docs/plans/host-effect-orchestration.md to origin/main (the LANDED version). KEEP ROADMAP.md + roadmap_authority.dag (the srv3 orphan-doc pointer — legit BMC scope). Do NOT touch the .dag or re-run main_wet — the drift ROOT (stale .dag) is the host-effect lane's to fix in a separate focused PR. EXPECTED: generated_artifact_drift_gate stays RED on #5773 until the host-effect lane's .dag fix lands on main; that is correct, not a regression to chase. Rebase on main after their fix merges. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
CI status: the single failing check is The root fix is #5790 (restores the |
Contributor
Author
|
CI @ 00ea6a9 has two RED gates, both pre-existing main breakages inherited via the main-merge (neither in this PR's 6-file diff):
main's own latest CI is RED on these same gates (run 28143366435, the #5795 push). This PR's in-scope content (BMC capability grounding + §5 honest srv3 row + 8 discriminating witnesses) is green by execution. Will rebase once both root fixes land; not chasing either here. — sent from sharp-stag-30 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Grounds srv3's BMC virtual-media install capability in the model and dispatches the OS-install mechanism off it — modeling only, zero seed code. Part of the BMC onboarding lifecycle (lane
sharp-stag-30underneat-boar-71).dsl/extdeps/bmc/capability.dag): addsCapabilityNbdProxyVirtualMediato theBmcCapabilitycoproduct — OpenBMC's nbd-proxy "proxy mode" virtual media (NBD carried in a secure WebSocket; the BMC is the NBD client, the server is ours), distinct from DMTF RedfishInsertMedia(CapabilityVirtualMedia). Named to OpenBMC's real term (citedopenbmc/jsnbd), not a client nickname (§3 single authority).dsl/gunbc/os_install_mechanism.dag):solve_install_mechanismprecedence — Redfish-VM > nbd-proxy-VM > firmware-update-then-VM > PXE.CapabilityNbdProxyVirtualMediauntil an operator-gated ws-upgrade dry-run confirms the nbd-proxy surface), so srv3 honestly solves toPxeHttpInstalltoday. The nbd-proxy dispatch arm is proven on a grounded synthetic row; flipping srv3's row is deferred to the PR that lands the dry-run confirmation receipt. (Review catch — commit288d855.)docs/plans/srv3-webui-kvm-virtual-media.md: architecture B (direct wss+NBD seed client, no browser/Playwright/JS) for sign-off; seed implementation gated behind the §6 operator dry-run. Inbound ROADMAP link added in the host-operation band (roadmap_authority.dag→ROADMAP.mdregen) so it is not a doc-graph orphan.Known-RED:
generated_artifact_drift_gate(pre-existing main drift, NOT this PR)The drift gate is latently RED on
mainand will show RED here until a separate fix lands:docs/plans/host-effect-orchestration.md's.dagauthority was regressed (Phase A status reverted to[now, parallel]while the committed.mdcorrectly says[LANDED #5756]). That is the host-effect lane's root to fix in a focused PR. This PR does not touch that doc or its authority — an earlier sweep attempt here was reverted (commit revertshost-effect-orchestration.mdtoorigin/main) because regenerating from the stale authority would ship false status (§5). Rebase-on-main after the host-effect fix merges greens it; do not chase it here.Test plan
Verified by execution (release
claim_executor/gunbc runon this branch):bmc_capability_solve_witness_test.dag).doc_graph_has_no_orphan_docs+doc_graph_has_no_dangling_linksPASS.roadmap_authority_witnesses+roadmap_document_witnessesPASS.generated_artifact_drift_gateis RED — pre-existing main drift in the host-effect doc authority (above), not introduced here.No seed code; HOLD for the wss+NBD client pending the operator dry-run call.