On Supermicro HGX systems (SYS-A21GE-NBRT) ~35 sub-chassis (GPU, NVSwitch, PCIeRetimer, ERoT/IRoT, BMC, FPGA) all carry ChassisType=Module/Component/Zone and expose empty /Drives collections. shouldAdaptiveNVMeProbe returned true for all of them, triggering 35 × 384 = 13 440 HTTP requests → ~22 min wasted per collection (more than half of total 35 min collection time). Fix: chassisTypeCanHaveNVMe returns false for Module, Component, Zone. The candidate selection loop in collectRawRedfishTree now checks the parent chassis doc before adding a /Drives path to the probe list. Enclosure (NVMe backplane), RackMount, and unknown types are unaffected. Tests: - TestChassisTypeCanHaveNVMe: table-driven, covers excluded and storage-capable types - TestNVMePostProbeSkipsNonStorageChassis: topology integration, GPU chassis + backplane with empty /Drives → exactly 1 candidate selected (backplane only) Docs: - ADL-018 in bible-local/10-decisions.md - Candidate-selection test matrix in bible-local/09-testing.md - SYS-A21GE-NBRT baseline row in docs/test_server_collection_memory.md Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
LOGPile Bible
Documentation language: English only. All maintained project documentation must be written in English.
Architectural decisions: Every significant architectural decision must be recorded in
10-decisions.mdbefore or alongside the code change.Single source of truth: Architecture and technical design documentation belongs in
docs/bible/. KeepREADME.mdandCLAUDE.mdminimal to avoid duplicate documentation.
This directory is the single source of truth for LOGPile's architecture, design, and integration contracts. It is structured so that both humans and AI assistants can navigate it quickly.
Reading Map (Hierarchical)
1. Foundations (read first)
| File | What it covers |
|---|---|
| 01-overview.md | Product purpose, operating modes, scope |
| 02-architecture.md | Runtime structure, control flow, in-memory state |
| 04-data-models.md | Core contracts (AnalysisResult, canonical hardware.devices) |
2. Runtime Interfaces
| File | What it covers |
|---|---|
| 03-api.md | HTTP API contracts and endpoint behavior |
| 05-collectors.md | Live collection connectors (Redfish, IPMI mock) |
| 06-parsers.md | Archive parser framework and vendor parsers |
| 07-exporters.md | CSV / JSON / Reanimator exports and integration mapping |
3. Delivery & Quality
| File | What it covers |
|---|---|
| 08-build-release.md | Build, packaging, release workflow |
| 09-testing.md | Testing expectations and verification guidance |
4. Governance (always current)
| File | What it covers |
|---|---|
| 10-decisions.md | Architectural Decision Log (ADL) |
Quick orientation for AI assistants
- Read order for most changes:
01→02→04→ relevant interface doc(s) →10 - Entry point:
cmd/logpile/main.go - HTTP server:
internal/server/— handlers inhandlers.go, routes inserver.go - Data contracts:
internal/models/— never breakAnalysisResultJSON shape - Frontend contract:
web/static/js/app.js— keep API responses stable - Canonical inventory:
hardware.devicesinAnalysisResult— source of truth for UI and exports - Parser registry:
internal/parser/vendors/—init()auto-registration pattern - Collector registry:
internal/collector/registry.go