collect omits per-DIMM memory, per-CPU detail, and all GPU/PCIe devices despite being available via Redfish

[husseinharake]

Dear Support,

Running magellan collect against a real BMC returns only summary-level data for memory and CPU, and completely omits GPUs and other PCIe devices — even though this data is fully available from the same BMC via direct Redfish calls with the same credentials.

Environment:

Magellan: built from source, main branch, July 2026
OS: macOS (darwin/arm64), Go 1.26.5
Target node: GIGABYTE G482-Z51-00, BMC firmware 12.41.12, Redfish v1.7.0

magellan collect --insecure https:// -F json -u -p -o collect.json

curl -sk -u : https:///redfish/v1/Systems/Self/Memory
curl -sk -u : https:///redfish/v1/Systems/Self/Processors
curl -sk -u : https:///redfish/v1/Chassis/Self/PCIeDevices

What collect returned:

Memory: aggregate only — "memory_total": 488 (GiB)
CPU: "processor_count": 2, generic "processor_type" string, no cores/threads/clock
GPUs/PCIe devices: not present in output at all

What raw Redfish actually has, on the same node:

Memory: 32 DIMM slots, individually queryable — 16 populated (Kingston DDR4, 3200MHz, ~30.5GiB each), 16 empty, each with health status
Processors: full detail per-CPU — 64 cores / 128 threads, 3400MHz max, x86-64, health status
PCIe devices: 7 total, including 4x NVIDIA Tesla V100 32GB GPUs, 1x Mellanox ConnectX-4, 2x Intel X550T 10G NICs — none of this shows up in collect output

Impact:
For GPU-bearing nodes especially, this means SMD's hardware inventory will show zero GPUs for a node that actually has four, since collect is the mechanism that feeds SMD. Anyone relying on Magellan+SMD for GPU-aware scheduling or asset tracking would have no visibility into this.

Expected behavior:
collect should walk and include full Memory, Processors, and Chassis/PCIeDevices collections (not just top-level summaries), matching what's already reachable via direct Redfish queries with the same credentials.

[davidallendj]

That was done intentionally by design. Originally, we determined early on the bare minimum needed to a node and decided to only included what was necessary for that. It shouldn't be difficult to add additional inventory info in the output, but I think we would want to add it as something that's optional. We would also have to looking into parsing the output in SMD so the info would be available with other OpenCHAMI services as well.

[husseinharake]

Thanks for the context, makes sense as a deliberate scoping choice rather than a bug. To understand direction here: when you say this would be added as "something optional," do you have a sense of what shape that would take? For example:

A single flag like --full / --verbose-inventory that pulls everything at once
Per-component flags (--include-memory-detail, --include-gpus, --include-processors, etc.) so users can opt into just what they need
Something else entirely (a config file option, a separate subcommand, etc.)

Also curious whether the SMD-side parsing work would need to land first, or whether these could be developed somewhat independently (i.e. Magellan collects it and stores it in the JSON output regardless, and SMD ingestion catches up later).

Mainly trying to understand what an eventual accepted solution would look like, so I know whether to keep working around this at the Redfish level in the meantime or whether something's already in motion.

Best regards
Hussein

[davidallendj]

Thanks for the context, makes sense as a deliberate scoping choice rather than a bug. To understand direction here: when you say this would be added as "something optional," do you have a sense of what shape that would take? For example:

A single flag like --full / --verbose-inventory that pulls everything at once
Per-component flags (--include-memory-detail, --include-gpus, --include-processors, etc.) so users can opt into just what they need
Something else entirely (a config file option, a separate subcommand, etc.)

Also curious whether the SMD-side parsing work would need to land first, or whether these could be developed somewhat independently (i.e. Magellan collects it and stores it in the JSON output regardless, and SMD ingestion catches up later).

Mainly trying to understand what an eventual accepted solution would look like, so I know whether to keep working around this at the Redfish level in the meantime or whether something's already in motion.

Best regards
Hussein

That's understandable. I'm thinking of a combination of an --include for collect as well as adding it to the config. By default, it would behave like it does now and you can include more by doing something like --include=memory,gpu,cpu or maybe have an --include=all option. Nothing is in motion just yet since this is the first time it's been brought IIRC but I can definitely look into adding something like this soonish.

[Masber]

what about adding a new --raw argument to the magellan collect command so it just returns the same json it receives from the redfish endpoint? optionally could add a --filter [mem|proc|accel|etc] argument to filter

[davidallendj]

what about adding a new --raw argument to the magellan collect command so it just returns the same json it receives from the redfish endpoint? optionally could add a --filter [mem|proc|accel|etc] argument to filter

I kind of like that idea of a --raw flag. I would have to think a little bit more about the --filter flag though.