Files
logpile/bible-local
Mikhail Chusavitin 1eb639e6bf redfish: skip NVMe bay probe for non-storage chassis types (Module/Component/Zone)
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>
2026-03-12 13:38:29 +03:00
..

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.md before or alongside the code change.

Single source of truth: Architecture and technical design documentation belongs in docs/bible/. Keep README.md and CLAUDE.md minimal 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: 010204 → relevant interface doc(s) → 10
  • Entry point: cmd/logpile/main.go
  • HTTP server: internal/server/ — handlers in handlers.go, routes in server.go
  • Data contracts: internal/models/ — never break AnalysisResult JSON shape
  • Frontend contract: web/static/js/app.js — keep API responses stable
  • Canonical inventory: hardware.devices in AnalysisResult — source of truth for UI and exports
  • Parser registry: internal/parser/vendors/init() auto-registration pattern
  • Collector registry: internal/collector/registry.go