aac3a69526
Auditors can now send BIOS/Redfish platform settings via
POST /ingest/hardware as hardware.platform_config (map[string]any).
Stored as latest-snapshot per machine with per-key change history.
Exposed via GET /api/assets/{id}/platform-config and .../history.
Asset page gets a third tab "Platform Config" with inline history expand.
Contract bumped to v2.9, migration 0024 adds two new tables.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
ADR: Platform Config — Storage and UI Tab
Date: 2026-03-19 Status: Accepted
Context
Auditors collect platform settings (BIOS parameters from Redfish) and want to transmit them via the existing POST /ingest/hardware endpoint. These settings need to be stored and displayed on the asset page.
Decision
- Add an optional
hardware.platform_configfield to the ingest contract: a free-formmap[string]anyobject (keys are strings, values are strings/numbers/booleans). - Store as a latest-snapshot per machine in
machine_platform_config(upserted on each ingest). - Track per-key change history in
machine_platform_config_history— a new row is inserted whenever a key value changes or first appears. - Expose via two new API endpoints:
GET /api/assets/{id}/platform-config— current snapshot with per-key change countsGET /api/assets/{id}/platform-config/{key}/history— history for a specific key
- Display in a third tab "Platform Config" on the asset page (alongside Current Components and Host Logs).
Rationale
map[string]anykeeps the contract simple and avoids premature schema design for BIOS parameters that vary by vendor.- Latest-snapshot + change history separates two use cases: quick audit view (current state) vs. change tracking (what changed and when).
- Reuses the existing ingest transaction and tab UI pattern, minimizing new infrastructure.
Consequences
- Platform config contents are not validated by the system — integrators are responsible for key naming consistency.
- History is append-only per key change; no compaction/TTL is applied initially.