Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
Problem
BMCs are the primary out-of-band (OOB) observability interface across the fleet, but they are resource-constrained and fragile under concurrent access. Today, multiple systems (monitoring, diagnostics, ad-hoc tooling) query BMCs directly, creating:
- Thundering herd effects during incidents or polling bursts
- Increased latency and timeouts under load
- Risk of degraded or unavailable BMC interfaces
- Lack of centralized auth, rate limiting, and access patterns
As fleet scale increases (NVL72, GB300-class systems), direct fan-out to BMCs becomes operationally unsafe.
Proposal
Introduce a BMC Proxy Cache Service that sits between clients and BMCs, acting as the single ingress point for all BMC queries.
Core behavior:
- Proxy all BMC HTTP/Redfish requests through a service endpoint
- Cache responses using an LRU strategy with TTL derived from cache headers or policy
- On cache hit: return cached JSON immediately
- On cache miss: fetch from target BMC, cache response, return to client
- Handle authentication centrally (credential abstraction / rotation)
Reference implementation (early prototype):
https://github.com/dathan/go-bmc-proxy-cache
Key Capabilities
- Thundering herd protection via request coalescing + caching
- Rate limiting / backpressure to protect BMC endpoints
- Centralized auth (no credential sprawl across clients)
- Consistent API surface regardless of BMC vendor quirks
- Improved latency for high-frequency reads (thermal, power, GPU health)
Integration with NICO
- NICO already acts as a control plane / DNS authority
- BMC FQDNs can be resolved to the proxy layer instead of direct endpoints
- Enables transparent interception without requiring client changes
Open Questions / Design Considerations
- Cache invalidation strategy (TTL vs event-driven vs write-through)
- Handling mutable operations (POST/PATCH) — bypass cache or enforce serialization
- Multi-tenant isolation and auth boundaries
- Failure modes (proxy down vs BMC direct fallback)
- Observability of the proxy itself (latency, hit rate, BMC error propagation)
- Consistency guarantees vs freshness (trade-off tuning per endpoint)
Why This Matters
At scale, BMCs cannot be treated as horizontally scalable services. Without an intermediary, we risk:
- Cascading failures during incidents
- Increased MTTR due to degraded observability
- Unbounded client behavior impacting critical OOB systems
This service establishes a controlled, scalable access pattern for all BMC interactions.
Feature Description
From a request perspective, I do not want to worry about crashing the BMC.
Describe your ideal solution
No response
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct
Is this a new feature, an enhancement, or a change to existing functionality?
New Feature
How would you describe the priority of this feature request
Medium
Please provide a clear description of problem this feature solves
Problem
BMCs are the primary out-of-band (OOB) observability interface across the fleet, but they are resource-constrained and fragile under concurrent access. Today, multiple systems (monitoring, diagnostics, ad-hoc tooling) query BMCs directly, creating:
As fleet scale increases (NVL72, GB300-class systems), direct fan-out to BMCs becomes operationally unsafe.
Proposal
Introduce a BMC Proxy Cache Service that sits between clients and BMCs, acting as the single ingress point for all BMC queries.
Core behavior:
Reference implementation (early prototype):
https://github.com/dathan/go-bmc-proxy-cache
Key Capabilities
Integration with NICO
Open Questions / Design Considerations
Why This Matters
At scale, BMCs cannot be treated as horizontally scalable services. Without an intermediary, we risk:
This service establishes a controlled, scalable access pattern for all BMC interactions.
Feature Description
From a request perspective, I do not want to worry about crashing the BMC.
Describe your ideal solution
No response
Describe any alternatives you have considered
No response
Additional context
No response
Code of Conduct