feat(machine-a-tron): expose machine status over HTTP

[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

machine-a-tron owns mock machine lifecycle and runtime endpoint allocation, but external tooling does not have a stable machine-readable way to discover active machine status.

This is needed by local and Kubernetes deployment tooling that must expose mock BMCs through environment-specific networking. Tooling needs to know which mock machines exist, their current state, BMC identity/IP, and the Redfish/IPMI ports that are active for each BMC. That information should come from machine-a-tron, not from duplicated allocation logic, logs, or hard-coded assumptions.

Feature Description

As a local/deployment tooling developer, I want machine-a-tron to expose machine status over HTTP, so that other components can discover active mock machines and their BMC endpoint details.

Machine-a-tron shall expose:
GET /machines/status

The response shall include machine lifecycle state and BMC endpoint information, including Redfish and IPMI ports when applicable.

Describe your ideal solution

Add or enable a machine-a-tron control HTTP API and expose GET /machines/status.

The implementation should reuse or extend the existing status data already used by the TUI, but return a stable serializable DTO rather than TUI-specific formatting.

Example response shape:

  {
    "machines": [
      {
        "mat_id": "...",
        "machine_id": "...",
        "hardware_type": "wiwynn_gb200_nvl",
        "mat_state": "Running",
        "api_state": "Available",
        "power_state": "On",
        "machine_ip": "172.21.0.20",
        "bmc": {
          "ip": "172.20.0.20",
          "redfish": {
            "reachable_port": 443,
            "listen_port": 8443
          },
          "ipmi": {
            "reachable_port": 623,
            "listen_port": 16020
          }
        },
        "dpus": []
      }
    ]
  }

Exact field names can follow existing machine-a-tron conventions, but the contract should distinguish the port clients should use from the internal listen/target port.

This issue should not require machine-a-tron to create Kubernetes Services.

Describe any alternatives you have considered

• Hard-code BMC endpoint data in local-carbide or Helm.
  - Rejected because machine-a-tron should remain the source of truth.

  • Add a machine-a-tron CRD.
    • Rejected for now; the desired state can be exposed through HTTP.
    • We don't want to make machine-a-tron k8s-aware

Additional context

This endpoint is intended to support follow-up Kubernetes Service reconciliation and IPMI/SOL simulation.

Likely affected modules:

• crates/machine-a-tron
• crates/bmc-mock, if BMC endpoint status needs to be surfaced from mock state
• local-carbide/Helm consumers in follow-up work

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

[poroh]

Reopening because /machines/status does not yet expose the IPMI endpoint described in this issue.

It should report each BMC’s client-facing and dynamically allocated listen ports. This is required by #3380 to map the Kubernetes Service port to the correct UDP target port.