feat(machine-a-tron): expose versioned InfiniBand inventory

[poroh]

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

A standalone UFM simulator needs a stable API from which it can discover complete machine and port inventory regardless of BMC deployment mode.

Feature Description

Machine-a-tron shall expose API containing a complete, versioned snapshot of its IB inventory.

Describe your ideal solution

Extend the existing stable GET /machines/status response with the InfiniBand inventory required by the UFM simulator. Do not introduce another listener or inventory endpoint.

Keep the change backward-compatible for the existing Web consumer by preserving all current fields and adding:

• A response-level stable source_id identifying the machine-a-tron deployment.
• A response-level epoch_id containing the machine-a-tron process start time. It remains constant for the lifetime of the process and changes after every restart.
• An inventory generation that increases within an epoch whenever machines, IB ports, GUIDs, or simulated port states change.
• An infiniband_ports collection on each applicable machine containing its GUIDs and simulated port states.

Reuse the existing fields:

• mat_id as the machine-a-tron machine identifier.
• machine_id as the optional NICo machine identifier discovered from the Carbide API.
• hardware_type as the simulated hardware type.

Make InfiniBand port definitions part of machine-a-tron’s static machine inventory. The Redfish discovery response and /machines/status must use the same port definitions so they cannot report different GUIDs for the same machine. GUIDs must be deterministic, globally unique across machine-a-tron instances, and stable across restarts.

The resulting response should resemble:

  {
    "source_id": "mat-rack-01",
    "epoch_id": "2026-07-14T22:35:18.123456789Z",
    "generation": 42,
    "machines": [
      {
        "mat_id": "dgxh100-01",
        "machine_id": "Machine_abc123",
        "hardware_type": "nvidia_dgx_h100",
        "infiniband_ports": [
          {
            "guid": "94dae00000000001",
            "state": "active"
          }
        ],
        "dpus": []
      }
    ]
  }

Describe any alternatives you have considered

Add a separate InfiniBand inventory endpoint

Introduce an endpoint such as /infiniband/inventory. This would provide a focused contract but duplicate machine identity, hardware type, and lifecycle data already exposed by /machines/status. It would also create two inventory APIs that could drift. Extending the stable status response is simpler and remains useful to the Web UI.

Discover ports by querying each simulated Redfish endpoint

The UFM simulator could scrape Redfish discovery data directly. This would require understanding multiple hardware-specific representations, contacting every simulated BMC, and reconstructing machine ownership. It would also couple UFM simulation scale to the number of running BMC simulations.

Embed a UFM simulator in every machine-a-tron process

Each machine-a-tron could expose its own UFM API. NICo would then need multiple fabric configurations for what may logically be one fabric, and large-scale tests would require many UFM instances. A standalone UFM simulator can aggregate several machine-a-tron inventories into one simulated fabric.

Configure UFM ports statically

The simulator could read a fixed list of GUIDs from configuration. This is suitable for small isolated tests but would not follow machine-a-tron lifecycle changes and could diverge from the GUIDs NICo discovers through Redfish.

Additional context

No response

Code of Conduct

• I agree to follow NVIDIA Infra Controller's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request