Software EBOM & Protocol Documentation
Deliverable 1 of Phase 12. A worked software EBOM and an ODM-facing interface spec — the contract that keeps a multi-party (you + Pegatron + ISVs) build coherent (WARMUP Ch. 2–3). Fill in the bracketed parts for your own node/rack; the result is both a real artifact and an interview portfolio piece.
Part A — Software/Firmware EBOM (example: one AI compute node)
The versioned, authoritative inventory reconciled against discovered reality at commissioning (Phase 01). A mismatch is a finding raised to the ODM, not a silent acceptance.
Firmware components & baseline (Phase 08)
| Component | Baseline version | Signed | A/B banks | Update path | Owner |
|---|---|---|---|---|---|
| BIOS/UEFI | 2.4.1 | yes (vendor key) | yes | Redfish UpdateService | ODM (Pegatron) |
| BMC (OpenBMC) | obmc-1.8.0 | yes | yes | Redfish + recovery | Us + ODM (upstream) |
| NIC/DPU | nic-fw-3.2.0 | yes | no | in-band agent | NIC vendor |
| Accelerator | accel-fw-2.1.0 | yes | yes | vendor tool / Redfish | Accelerator vendor |
| PSU | psu-1.0.3 | yes | no | BMC (PMBus) | ODM |
| PCIe switch | pex-4.1 | yes | no | BMC | Switch vendor |
| CPLD | cpld-0.7 | n/a | no | JTAG/BMC | ODM |
Software components (Phase 11 compatibility)
| Component | Version | Depends on | Compat window |
|---|---|---|---|
| rack-agent (DaemonSet) | 1.5.x | control-plane ≥ 1.4 | N-1 control-plane |
| metrics exporter | 1.3.x | Prometheus ≥ 2.40 | — |
| RackNode operator | 0.9.x | k8s ≥ 1.27 / RKE2 | — |
Interfaces & config baselines
- Management: Redfish (primary), IPMI (fallback), SNMP (PDU/switch) — see Part B for the spec.
- Secure boot (Phase 09): PK/KEK provisioned; db includes
[keys]; dbx revokes[list]. - Network (Phase 09): mgmt VLAN
10, tenant VLANs100–199; mgmt reachable control-plane-only. - Power/thermal budget (Phase 01): derated feed
17.3 kW; CDU130 kW; N+1.
Provenance / traceability
- Each row: source, license, support status, security-contact, last-validated date.
- Reconciliation rule: at commissioning, discovered firmware/software/topology MUST match this EBOM; deviations are logged as findings and triaged with the responsible owner.
Part B — Interface Specification (ODM-facing, example: node power & telemetry)
Precise + testable enough that the ODM builds the same thing without us in the room (WARMUP Ch. 3). Pair every requirement with a conformance check (Part C).
B.1 Standard & deltas
- Base: DMTF Redfish
2023.2. - Required resources:
ServiceRoot,Systems/{id}(withPowerState,ProcessorSummary,Actions/#ComputerSystem.Reset),Chassis/{id}withPowerandThermal,Managers/{id},UpdateService,EventService,TaskService. - OEM extensions:
Oem/Rackmgrblock onChassisMUST exposeRackPosition,PowerBudgetW.
B.2 Behavior (not just shape)
- Reset action: MUST advertise
ResetType@Redfish.AllowableValuesand support{On, ForceOff, GracefulShutdown, ForceRestart, GracefulRestart, PowerCycle}. AGracefulShutdownto a hung host MUST NOT report success if the host did not power off (Phase 04 escalation relies on this). - Firmware update:
UpdateService.SimpleUpdateMUST return202+ aTask;TaskStatetransitionsNew→Running→Completed|Exception; activation requirements stated per component (Phase 08). - Sensors:
Thermal.Temperatures[]MUST includeinletand per-acceleratoraccelNwithReadingCelsiusandUpperThresholdCritical; units Celsius; names as listed. - Errors: failures return a Redfish error body with
@Message.ExtendedInfo; a4xxfor client errors,5xxfor service errors — never200with an error body. - Auth: HTTPS only; Session tokens via
SessionService; certificate chains to the management CA. - Timing/resilience: the BMC SHOULD respond within
[N]s; clients will retry with backoff (Phase 02) — the BMC MUST be idempotent for repeatedGET/action submissions.
B.3 Events
EventServiceMUST support subscriptions (EventDestination) and SHOULD support SSE; PSU/thermal/ fault events MUST be emitted (so we don't rely on polling alone — Phase 07).
Part C — Conformance hooks (the spec's executable form)
Prose drifts; tests don't (WARMUP Ch. 3; Phase 11). Each requirement maps to a conformance check the ODM runs against their firmware in CI/HIL.
| Req (B.x) | Conformance check |
|---|---|
| B.1 resources | GET each required resource; assert presence + @odata.type |
| B.2 Reset values | assert AllowableValues ⊇ required set; illegal ResetType → 4xx |
| B.2 firmware Task | submit update → assert 202 + Task; poll to terminal state |
| B.2 sensors | assert inlet+accelN present with thresholds, correct units |
| B.2 errors | force an error; assert 4xx/5xx + extended info (never 200+error) |
| B.3 events | subscribe; trigger a fault; assert delivery |
Deliver this suite to the ODM; a failing check is an unambiguous, non-negotiable defect.
How to use this deliverable
- Replace the bracketed/example values with your node's real components and interface.
- Wire Part C into the Phase 11 conformance harness (run against the Redfish emulator + HIL).
- Version this document (changelog + compatibility notes — Phase 11 Ch. 5); assign an owner.
- Use it as the commissioning reconciliation source (Phase 01) and the ODM defect-feedback basis.