[RFD]: Flexible Hardware Identification and Hierarchy Linking

[bmcdonald3]

Decision Goal

Establish a standard for identifying hardware components and linking parent/child relationships when physical serial numbers are unavailable (e.g., chassis, racks, or non-serialized FRUs).

Category

Architecture

Stakeholders / Affected Areas

Sys Admins, collector developers, OpenCHAMI Core

Decision Needed By

No response

Problem Statement

Summary

The fru-tracker currently uses a strict serialNumber requirement for both unique identification and hierarchy linking. While effective for standard server components, this model fails at the chassis and rack levels where serial numbers may be missing or inaccessible to certain management protocols. We need a reconciliation strategy that supports fallback identifiers like Redfish URIs or Asset Tags without breaking the existing event-driven model.

Current State

Today, the Device resource requires a serialNumber in its Spec. The DiscoverySnapshotReconciler uses this serial to perform "get-or-create" operations and uses parentSerialNumber to resolve the parentID (UUID) for children. If a collector encounters a chassis without a serial, the API rejects the record, and child components (Nodes) cannot be linked to their physical enclosure.

Goals

• Enable tracking of hardware that lacks a physical serial number.
• Maintain the "Two-Pass" reconciliation model to ensure all devices are created before links are resolved.
• Clean up the DeviceStatus model by removing unused fields like ChildrenDeviceIds.

Non-goals

• Replacing the internal UUID (uid) as the primary system-of-record key.
• Implementing a full "Location" service; this remains focused on the FRU hierarchy.

Proposed Solution

We propose maintaining serialNumber as the primary identifier but updating the reconciler to support alternative keys when the serial is absent:

• The reconciler will attempt to find a device by SerialNumber. If not provided, it will fall back to the redfish_uri stored in the Properties map.
• Introduce a parentURI lookup. If parentSerialNumber is missing, the reconciler will use the redfish_parent_uri property to locate the parent resource's UUID.

Alternatives Considered

• Strict URI-only Identification: Rejected because serial numbers are more stable than Redfish paths, which can change if the management tree is reorganized.
• External Mapping Table: Rejected as it adds a third-party dependency (like a separate spreadsheet or database) into the hot path of the collector's reconciliation loop.

Other Considerations

• Risks: Allowing multiple types of identifiers could lead to duplicate device records if a collector provides a Serial in one snapshot and only a URI in the next.
• Mitigation: The reconciler must enforce a strict precedence (always check Serial first).

Related Docs / PRs

• https://github.com/OpenCHAMI/fru-tracker?tab=readme-ov-file#device-data-model
• https://github.com/OpenCHAMI/fru-tracker/blob/main/apis/example.fabrica.dev/v1/device_types.go

[alexlovelltroy]

@j0hnL is likely to have some thoughts on this.

[j0hnL]

The serialNumber → redfish_uri fallback with strict serial-first precedence makes sense.

Are there consideration for deeper hierarchies beyond node → chassis? Like Rack → Chassis → Node → CPU/DIMM

[bmcdonald3]

Yeah, the data model supports arbitrarily deep hierarchies. The design uses an adjacency list pattern for relationships rather than fixed tiers.

Hierarchy is established through generic parent pointers (ParentID and ParentSerialNumber) on the device record. The RFD extends this mechanism by adding redfish_parent_uri as a fallback property, operating on the same parent-child linking logic.

The DeviceType field is an open string.

As long as the collector provides the requisite parent identifier (Serial or URI) for any given component, the reconciler will link them up the tree, supporting chains like Rack → Chassis → Node → CPU → DIMM without needing schema changes.