BMC onboarding lifecycle for new Altra server (BMC 192.168.1.192): model factory-default login through cred-rotate through OS-install through fabric-setup as .dag over Redfish, building on dsl extdeps bmc + tools bmc_first_contact

[briansrls]

Models the onboarding lifecycle of the operators new Altra server (BMC 192.168.1.192) from factory-default login through cred-rotate, OS-install, and fabric-join, as a .dag lifecycle over Redfish. Builds on the existing extdeps/bmc telemetry seam.

Layering (DESIGN §3)

• extdeps/bmc/types.dag — real DMTF Redfish write-side enums (RedfishBootSourceOverrideTarget, ...Enabled, RedfishResetType, RedfishAccountRole) + faithful wire-token projections (Pxe, Administrator, …).
• extdeps/bmc/http.dag — interface shapes for the transition-effecting Redfish ops: GetServiceRoot (read), SetAccountPassword, SetBootSourceOverride, ResetSystem (writes). Transport = the existing curl/netrc shell handler. The new secret rides a runtime request_body_file, never argv or the repo.
• gunbc/bmc_onboarding.dag (workflow / business policy) — BmcOnboardingPhase (FactoryDefault → CredentialsRotated → OsInstalled → FabricJoined), derived successor/completion (single ordering authority), and the BmcOnboardingPlan for the new server: host .192, OpenBMC factory login, Stored rotated credential (secret named, not stored), Ubuntu Noble target, Pxe boot override.
• gunbc/tools/bmc_onboard.dag — runnable READ-ONLY first-contact + inventory validation. Write transitions are modeled but gated — not driven here.
• test/claim witness — linear-DAG phase ordering + plan grounding.

Verified by execution

• Witnesses green (gunbc run --claim-run).
• Compile-clean: 0 diagnostics across 420 modules.
• Read path green against the live BMC at 192.168.1.192: GetServiceRoot + GetSystem (factory creds root/0penBmc) → ExitSuccess.

Grounding finding

VirtualMedia is absent on this OpenBMC firmware (404 at both standard paths), so OS-install is modeled via boot-source-override (Pxe) + ComputerSystem.Reset, not VirtualMedia insert — faithful to what the live API returns.

Destructive transitions (cred-rotate, OS-install) are modeled but not executed; they stay gated behind operator confirmation per the lane safety fences.

[gunbai-bot]

Thanks for the review. Both nits addressed:

Nit 1 (phase_order duplicates next_phase — §3): Fixed in e8f2958. Deleted the standalone bmc_onboarding_phase_order roster; bmc_onboarding_next_phase is now the sole authority for the linear successor relation. The witness already proves the full 4-phase ordering + completeness via the per-phase next_tag chain (FactoryDefault→1→2→3, FabricJoined→terminal), so the roster phase_count==4 check was subsumed — no consumer lost. Compile-clean (0 diag/420 modules) + both witnesses green by execution after the change.

Nit 2 (is_complete = the is_none predicate shape): Agreed it should route through a canonical Optional.is_absent once std/ grows one. Leaving the local match … { Absent ⇒ true; Present ⇒ false } as the minimal correct form with a dissolution target of that future std predicate — minting an is_absent in std/ is out of this lanes scope (load-bearing std change) and you flagged it non-blocking.

Note: the modeling-coherence check shows UNAVAILABLE on this PR, but the failure reason is a host-gunbc/ctrl pin skew (host tree behind the ctrl pin, cant satisfy std.reducible/#5208 imports the checkout added) — head-independent infra, unrelated to this diff (which touches no std.reducible). Operator is routing it.

— sent from neat-boar-71

[gunbai-bot]

Thanks — both findings addressed:

Finding 1 (tool name oversells the shipped scope): Fixed in e9cdc37. Renamed the module + file gunbc.tools.bmc_onboard → gunbc.tools.bmc_onboard_validate. The tool genuinely only does the read-only FactoryDefault validation (GetServiceRoot + GetSystem), so the honest name now matches the shipped behavior, and it frees bmc_onboard for the future (gated) full-lifecycle driver. Compile-clean (0 diag/420 modules) + the validator still runs read-only against the live BMC green by execution after the rename.

Finding 2 (is_complete predicate-dissolution): No change — agreed its advisory in workflow-layer and, as you noted, it already routes through the canonical bmc_onboarding_next_phase (consumes the surface, no hand-rolled recursion). It has no siblings today; if completion checks grow, Ill express them via next_phase at the call sites / route through a canonical Optional.is_absent once std/ grows one.

— sent from neat-boar-71

[gunbai-bot]

Thanks — addressed:

Finding 1 (delete is_complete): Done in 7d3e227. The predicate had a single caller (the witness), and the witness's next_tag chain already proves completion (FabricJoined → -1 = terminal; the others → 1/2/3). Deleted the helper + its now-redundant witness lines; bmc_onboarding_next_phase stays the sole successor authority. Compile-clean + both witnesses green by execution.

Finding 2 (model next_phase as a [Phase] data literal with next derived): Holding as-is, because this directly reverses the earlier review on this PR (artifact /api/reviews/31835), which flagged exactly that list — bmc_onboarding_phase_order = [FactoryDefault, …] — as duplicating next_phase (two authorities for one successor relation, §3) and had me delete it. The two notes are in tension, so Im resolving toward the §3 single-authority reading: for a closed 4-variant enum, the linear order needs exactly one irreducible match to bind variant-names to positions — there is no enum equality, so deriving next from a [Phase] literal would require a phase_eq/phase_index match, which relocates the irreducible match rather than removing it and re-introduces the duplication the earlier review eliminated. next_phase is that single authority (the successor relation itself), and its consumed (the witness next_tag). If the lifecycle later grows a second axis (as you note), Ill revisit with the order as a first-class data structure. Happy to flip if youd prefer the list form — just flagging the prior-review conflict so its a deliberate call, not a loop.

— sent from neat-boar-71