BMC Discovery - Pre-configured iDRAC Discovery w/ Magellan

This is a design-level feature spanning OpenCHAMI Magellan discovery, the Omnia DB, and DHCP host reservations, and the body names no existing file, test or entry point to start from. Before any code, a maintainer needs to settle scope, the credential-source interface and the DHCP sync approach. Done means the five acceptance criteria (AC-001 to AC-005) are met on a real subnet.

BMC Discovery - Pre-configured iDRAC Discovery w/ Magellan

---

Summary

Deployment Engineers and Infrastructure Administrators need an automated Day 0 discovery mechanism to bring massive HPC clusters online without manually curating thousands of rows of MAC addresses in static mapping files. By leveraging OpenCHAMI Magellan to sweep the network, authenticate against heterogeneous BMC passwords, and automatically populate the Omnia database with host mappings and IP assignments, administrators can bootstrap 1,000+ node clusters in hours instead of weeks.

---

Problem Statement

Today, booting a cluster with Omnia requires administrators to provide a manually curated static mapping file (e.g., a CSV) containing precise MAC addresses, IP assignments, and hostname mappings for every node. This manual process is tedious, highly error-prone, and fundamentally unscalable for representative large-scale environments with 1,000+ nodes. Building and verifying a spreadsheet for 1,000+ nodes requires weeks of labor. Without an automated Day 0 discovery mechanism to sweep the BMC network, associate identities, and auto-assign IP addresses, Omnia deployments for enterprise-scale HPC deals are stalled by massive administrative overhead.

---

Value Proposition

Customer Value

Customers deploying large clusters no longer have to trace cables or scan BIOS screens to manually record thousands of MAC addresses into a spreadsheet. By simply providing an IP range and BMC credentials, the system automatically discovers the physical hardware, maps the iDRAC MAC to the Host MAC to the Service Tag, and auto-generates the internal inventory. This completely eliminates human error during the initial cluster bootstrap.

---

User Personas

• Deployment Engineer / Infra Admin: Responsible for the initial physical rack-and-stack and the Day 0 bootstrap of the Omnia cluster. Needs automated discovery to bring the cluster online without curating massive spreadsheets.

---

Use Cases

Use Case 1: Automated Day 0 Node Discovery

Actor: Infra Admin
Context: A 1,000+ node cluster has been racked, cabled, and powered on.
Action: The administrator provides Omnia with an iDRAC IP range and an approved protected BMC credential source, triggering Magellan discovery.
Result: Magellan sweeps the network, successfully authenticates to each BMC, extracts the MAC addresses and Service Tags, and populates the Omnia DB. The nodes are now ready for PXE boot and OS provisioning without a manual mapping file.

---

Scope Definition

Goals (Execution Outcomes)

• Utilize OpenCHAMI Magellan to sweep an IP range and discover BMCs (iDRAC).
• Automatically associate the iDRAC MAC to the Host MAC to the Service Tag and assign a hostname.
• Auto-assign IP addresses for each discovered network and save this information to the Omnia DB.
• Handle heterogeneous, pre-configured passwords (per security requirements).

Non-Goals (Scope Boundaries)

• Transitioning the Omnia DB to use OpenCHAMI SMD as the definitive source of truth in this phase (Omnia DB remains primary, generating temporary SMD files at execution time).
• Auto-reassignment or rotation of BMC passwords (handled in a separate "Advanced BMC Management" capability).
• Discovering deep FRU/Component states (deferred to JA-9043).

---

Requirements

Requirement: Magellan BMC Network Sweep [Req 1]

The system must utilize Magellan to sweep a defined IP subnet to discover active BMC interfaces and extract core identity markers.

Relates to: Use Case 1 - Automated Day 0 Node Discovery

Scenario: Successful Sweep

• When the discovery playbook executes, the system associates each node's iDRAC MAC, Host MAC, and Service Tag accurately.

Requirement: Heterogeneous Password Handling [Req 2]

The system must support authenticating against BMCs that shipped with unique, per-node factory passwords.

Relates to: Use Case 1 - Automated Day 0 Node Discovery

Scenario: Authenticating with Unique Passwords

• When discovery runs, the system uses the approved protected BMC credential source to authenticate against each unique BMC.

Requirement: Database Population and IP Assignment [Req 3]

The system must automatically generate hostnames, assign IPs for designated networks, and populate the Omnia DB. Assigned static IPs must be automatically synchronized to the DHCP server configuration before any nodes are instructed to PXE boot, ensuring that nodes receive their correct IP assignments during the boot process. The provisioning workflow must not proceed to the boot step until the DHCP configuration has been updated and the DHCP service has reloaded the new configuration.

Relates to: Use Case 1 - Automated Day 0 Node Discovery

Scenario: Initial DB Population with DHCP Sync

• When discovered nodes are processed, the system auto-assigns IP addresses, writes the mapping data to the Omnia DB, and synchronizes the assigned IPs to the DHCP server configuration (host reservations). The DHCP service reloads the updated configuration before any nodes are instructed to PXE boot. This replaces the need for a static mapping file.

Scenario: DB Refresh vs Append

• When the admin runs discovery on a new subnet expansion, the admin can choose to append the new nodes to the existing DB or force a total refresh.

---

Telemetry

The Magellan BMC discovery process must expose metrics to track discovery success rates, authentication patterns, and database population accuracy. Engineering should utilize BMC Discovery's session logging and discovery status tracking, or custom logging for discovery scripts, to expose this data to the central observability stack.

---

Security

• The protected BMC credential source must be handled securely during discovery and excluded from deployment logs.

---

Documentation

• Admin Guide: Document how to reference an approved protected BMC credential source and describe the expected database outputs. Exact credential-source schemas and examples remain in restricted operational documentation.

---

Dependencies

• Magellan: OpenCHAMI Magellan must be able to extract the requisite MAC/Service Tag data from the BMCs (noting potential behavioral differences between x86 and ARM iDRAC implementations).
• IRC Rack Definition File (Optional Enrichment): When available, the RDF from the Integrated Rack Controller (IRC) provides rack elevation, component service tags, and MAC addresses. This data can serve as a cross-validation source for Magellan sweep results and as the primary source for physical location data that BMCs cannot reliably supply. Not required for provisioning.

---

Risks

Risk	Category	Impact	Likelihood	Mitigation
Missing Physical Location Data	Technical	Medium	Medium	iDRAC may lack the physical location data (rack, U/elevation) required to populate a strictly xname-compliant SMD. Partially mitigated: The Integrated Rack Controller (IRC) Rack Definition File (RDF) contains rack elevation and component service tags, providing an alternative source for physical location data. If IRC RDF is unavailable, fall back to dummy data during SMD generation or factory-embedded Asset Tag data. Note: physical location data does not block provisioning — it is required only for CMDB population (JA-9043) and maintenance operations.

---

Acceptance Criteria

• AC-001: OIM successfully identifies all iDRACs and Host MACs in a given IP range without a static mapping file. [Req 1]
• AC-002: The discovery process successfully authenticates against nodes with heterogeneous, unique factory passwords. [Req 2]
• AC-003: The system correctly auto-assigns IP addresses, populates the Omnia DB, and synchronizes the assigned IPs as host reservations in the DHCP server configuration. The DHCP service has reloaded before any nodes are instructed to PXE boot. A subsequent PXE boot by a discovered node receives its assigned IP from the DHCP server (not a random DHCP lease). [Req 3]
• AC-004: Non-PowerEdge devices are properly suppressed or segregated into alternate inventory groups. [Req 1]
• AC-005: The admin can successfully choose to append new nodes to an existing DB or perform a total refresh. [Req 3]

---

Scope & Sequencing

This capability constitutes the foundational "Day 0" cluster discovery increment. Deep component/FRU extraction and true CMDB tracking (JA-9043) are deferred to a subsequent "Day 2" increment, which will build upon this Magellan integration.

---

Assumptions / Open Questions

Assumptions

• A1: Omnia DB remains the source of truth for deployment, generating temporary SMD files for OpenCHAMI execution.
• A2: Physical location data (rack elevation, U-position) is not required for Day 0 provisioning. It is consumed downstream by CMDB population (JA-9043) and maintenance workflows.

Open Questions

• Q1: Is the IRC RDF format standardized across all deployments, or does it vary by deployment profile? (Determines whether a generic parser is sufficient or site-specific adapters are needed.)

---