Skip to content

hp_proliant_da_cntlr: do not discover phantom controllers#929

Open
Bastian-Kuhn wants to merge 1 commit into
Checkmk:masterfrom
Bastian-Kuhn:fix-hp-proliant-da-cntlr-phantom-discovery
Open

hp_proliant_da_cntlr: do not discover phantom controllers#929
Bastian-Kuhn wants to merge 1 commit into
Checkmk:masterfrom
Bastian-Kuhn:fix-hp-proliant-da-cntlr-phantom-discovery

Conversation

@Bastian-Kuhn

@Bastian-Kuhn Bastian-Kuhn commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

What

hp_proliant_da_cntlr no longer discovers phantom controllers.

Why

On HPE ProLiant Gen11 / iLO 6 the controller table (cpqDaCntlrTable) contains a placeholder row — typically index 0 — whose condition/role/board‑status/board‑condition cells are all 0 (a value the vendor MIB does not define). parse_hp_proliant_da_cntlr already parses such rows to None, but discovery_hp_proliant_da_cntlr iterated over all section keys and still discovered the phantom item, whose service was then permanently UNKNOWN ("Controller not found in SNMP data").

The controller table (cpqDaCntlrTable) on HPE ProLiant Gen11 / iLO 6 contains a
placeholder row -- typically index 0 -- whose condition, role, board status and
board condition cells are all '0', a value the vendor MIB does not define.
parse_hp_proliant_da_cntlr already parses such rows to None, but discovery
iterated over all section keys and still created a service for the phantom row,
which was then permanently UNKNOWN ('Controller not found in SNMP data').
Discovery now skips None entries.
@Bastian-Kuhn Bastian-Kuhn force-pushed the fix-hp-proliant-da-cntlr-phantom-discovery branch from 425517a to f9e3778 Compare July 3, 2026 13:00
@Bastian-Kuhn Bastian-Kuhn marked this pull request as ready for review July 3, 2026 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants