Listing Nodes

The Nodes page displays all compute nodes with their cluster affiliation, resource totals, and running job counts. When connected to a Federate cluster, a Cluster column identifies which underlying Orchestrate cluster each node belongs to.

Use the Status filter to narrow the list – most often to Unknown, to see the nodes the control plane has stopped hearing from. The filter is carried in the page URL, so a filtered view can be shared. A node carrying a hold is the one to look at first: a hold is what actually stops work being placed there, and it names who placed it and why.

Click a node to open its details, which include each hold with its source and reason – see Node Details.

List all compute nodes in the cluster:

$ fuzzball node list

ID               | CLUSTER  | HOSTNAME        | STATUS  | HOLDS        | JOBS
node-worker-01     fb-aws    worker-01.local   Ready     -              1
node-worker-02     fb-aws    worker-02.local   Ready     cordon         0
node-worker-03     fb-aws    worker-03.local   Unknown   -              2
node-worker-04     fb-aws    worker-04.local   Ready     cordon,evict   1

The output shows:

• ID: Unique identifier for the node
• CLUSTER: Resolved cluster name
• HOSTNAME: Network hostname
• STATUS: What Fuzzball has observed about the node – Ready, Not Ready, Offline, or Unknown before its first report
• HOLDS: What has been asked of the node, as the distinct effects held on it – cordon, evict, deprovision, or - when nothing is
• JOBS: Number of jobs currently running on this node

STATUS no longer reports a cordon. A cordoned node reads Ready with a cordon hold, because nothing is wrong with the hardware – somebody has simply asked that no new work go there. Reading STATUS alone therefore does not tell you whether work will be placed on a node; HOLDS does.

Effects rather than a count, because a count cannot answer the question: a node with one cordon hold and a node with one deprovision hold are not in the same situation, and both would read as 1.

See Node Health Monitoring for what each status means and how a silent node is detected.

For the full record (CPU type, total/allocated/available cores and memory, device summaries, the running fuzzball-substrate version, etc.) use -o yaml or -o json. When connected to a Federate cluster, the CLUSTER column distinguishes which underlying Orchestrate cluster each node is part of.

Each node record reports the running Substrate version (as reported by substrate itself) – shown as substrate_version in -o yaml output and substrateVersion in -o json output. It is not a column in the default table; use -o yaml/-o json or fuzzball node show to see it. In -o yaml the field is omitted for nodes running a substrate version that does not report it; in -o json it renders as an empty string.

Use the --available flag to compute the per-node available cores, memory, and devices alongside the totals (visible in JSON / YAML output):

$ fuzzball node list --available -o yaml

For programmatic access or scripting, use the -o json flag:

$ fuzzball node list -o json

This returns node information in JSON format suitable for parsing with tools like jq:

$ fuzzball node list -o json | jq '.[] | select(.running_jobs > 0)'