NAPALM/napalm-redfish
1
0 Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

docs: design notes for a Redfish/IPMI BMC driver

Browse Source 
No code yet. The README explains why one Redfish driver with vendor quirk
modules beats a Supermicro-only IPMI driver, and keeps IPMI over LAN as a
read-only fallback. docs/ holds a draft for a new ManagementController
role base in napalm-device-types, the getter-to-resource map, the first
test device (Supermicro X10DRL-i, Redfish firmware 3.91), the security
points (IPMI RAKP hash disclosure, power control, credentials) and the
test plan with DMTF mockups and fixtures to record.
This commit is contained in:
Christian Manivong committed 2026-10-13 01:15:57 +02:00
commit 5f8a4ef975
9 files changed
+557
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/testing.md
+47
View File
@@ -0,0 +1,47 @@
# Testing
## Without hardware
- **DMTF mockups (DSP2043).** Complete Redfish service trees as static JSON, published by
the DMTF with each Redfish release (download from the Redfish standards page). They cover
the current schema: `ThermalSubsystem`, `PowerSubsystem`, `Sensors`, storage, logs, and
actions.
- **DMTF Redfish-Mockup-Server.** Serves a mockup over HTTP (`127.0.0.1:8000` by default),
also as a Docker image `dmtf/redfish-mockup-server`. Good for integration tests of the
transport (sessions, collections, actions).
- **OpenStack sushy-tools.** An emulator that serves mockups or drives libvirt VMs via Redfish,
so `set_power_state` can be tested against something that actually changes state.
- **DMTF Redfish-Mockup-Creator.** Records a live service into a mockup. It is the tool to
turn the X10DRL-i into a complete fixture set in one go.
Unit tests use recorded JSON responses directly; the mockup server is for a small set of
integration tests.
## Fixtures to record from the X10DRL-i
Store under `tests/fixtures/supermicro-x10drl-i-3.91/`, one file per request path, plus
`COMMANDS.txt` with the paths and the machine's state (powered on/off, fans present).
Scrub serial numbers, UUIDs, MACs and IPs before committing.
- [ ] `GET /redfish/v1/` (without login)
- [ ] `GET /redfish/v1/Systems` and each member
- [ ] `GET /redfish/v1/Systems/1/Processors` and each member
- [ ] `GET /redfish/v1/Systems/1/Memory` and each member
- [ ] `GET /redfish/v1/Systems/1/Storage` or `SimpleStorage`, whichever exists
- [ ] `GET /redfish/v1/Systems/1/EthernetInterfaces` and each member
- [ ] `GET /redfish/v1/Systems/1/LogServices` and the entries of each
- [ ] `GET /redfish/v1/Chassis` and each member
- [ ] `GET /redfish/v1/Chassis/1/Thermal`
- [ ] `GET /redfish/v1/Chassis/1/Power`
- [ ] `GET /redfish/v1/Managers/1`
- [ ] `GET /redfish/v1/Managers/1/EthernetInterfaces` and each member
- [ ] `GET /redfish/v1/Managers/1/NetworkProtocol`
- [ ] `GET /redfish/v1/Managers/1/LogServices` and the entries of each
- [ ] `GET /redfish/v1/AccountService` and `AccountService/Accounts`
- [ ] `GET /redfish/v1/UpdateService/FirmwareInventory` and each member
- [ ] `POST /redfish/v1/SessionService/Sessions` response headers (token redacted)
- [ ] the error body of a request without credentials and of a wrong path
- [ ] `ResetType@Redfish.AllowableValues` from `Systems/1`
- [ ] IPMI: FRU, sensor list, chassis status, SEL (via `ipmitool` for comparison with `pyghmi`)
Or run the Redfish-Mockup-Creator once against the BMC and keep its output.