sinfo/spur nodes: node features (%f) not displayable — missing from NodeInfo proto and sinfo resolver

[yansun1996]

What happened

Node features configured in spur.conf (e.g. features = ["mi350x", "atl", "<hostname>"]) cannot be displayed via the CLI. sinfo/spur nodes with the %f (AVAIL_FEATURES) format specifier always prints ?:

$ sinfo -N -o "%n %f"
HOSTNAMES AVAIL_FEATURES
ml-ai-...-11 ?
ml-ai-...-03 ?
...

What was expected

%f should print each node's configured features, the same way Slurm's sinfo -o "%f" does — so users can see which labels are available to target with -C/--constraint.

Root cause (two gaps)

1. NodeInfo proto has no features field. proto/slurm.proto (message NodeInfo, ~line 201) carries name, state, total_resources, arch, os, switch_name, active_reservation, and labels (map, field 51) — but not the features list that NodeConfig (crates/spur-core/src/config.rs:497) and the scheduler use. So feature data never reaches the CLI.

2. resolve_node_field has no 'f' case. crates/spur-cli/src/sinfo.rs (~lines 175-219) handles N n P R t T c m G D a O e l but not f, so it falls through to _ => "?". The header map (format_engine.rs) does know 'f' => "AVAIL_FEATURES", which is why the column header renders but every value is ?.

Impact

• Constraint matching works correctly — the scheduler reads features from spur.conf directly. Verified: salloc -N 1 -C <hostname> allocates exactly that node, and -C mi350x matches by GPU type.
• Only the display is broken: there is no user-facing way to discover what features a node has. Users must read spur.conf (admin-only) to know what -C values are valid.

Suggested fix

1. Add repeated string features to NodeInfo in proto/slurm.proto.
2. Populate it from NodeConfig.features where the controller builds NodeInfo (crates/spurctld/src/server.rs).
3. Add a 'f' => node.features.join(",") case to resolve_node_field in crates/spur-cli/src/sinfo.rs.

Secondary note

%n (HOSTNAMES) only resolves in per-node mode (-N); without -N the grouped/partition view resolver (resolve_partition_field) returns ? for %n. This matches Slurm behavior reasonably (use %N in grouped view), but may be worth documenting.

Environment

• Spur 0.3.0
• 3-controller HA + 12 compute nodes

[shiv-tyagi]

Nodes registration in spur is dynamic. We would need to support this via node labels. Node agents can report labels while registering, we would need to map those to features.