resources.yaml(5)

🎀 NAME 🎀

resources.yaml — the Slurm configuration file for Hierarchical Resources (HRES), aka the YAML file that lets you stack your resources in layers like the absolute icon you are 💅

✨ DESCRIPTION ✨

okay so, <pink>resources.yaml</pink> is a YAML-formatted config file that defines your Hierarchical Resources (HRES). No cap. It has to live in the same directory as slurm.conf — they're roommates, they don't do long distance 🫶

And the comment rules? Literally so simple: any text following a # in this file is treated as a comment through the end of that line. That's it, that's the whole vibe 💬

Want even more tea? There are additional details on the Hierarchical Resource (HRES) Scheduling page: https://slurm.schedmd.com/hres.html 🦋

🌸 PARAMETERS 🌸

Each Hierarchical Resources definition is a YAML object, and every one of them contains these attributes:

• resource — the unique name for the resource, bestie. This name is how slurmctld identifies it. And heads up: this must be the first attribute in the object. Not second, not "somewhere in there". First. 👑
• mode — the planning mode for the resource. It has to be one of these three, pick your fighter:
  • MODE_1 — sufficient resources are required on only one layer that overlaps with the job's allocated nodes.
  • MODE_2 — sufficient resources must be available on all layers that overlap with the job's allocated nodes.
  • MODE_3 — resources are allocated on a per-node basis. The scheduler calculates total consumption from the most granular layer and sums it up into the successively higher layers, making sure the count is not exceeded at any layer. This mode is designed for consumable resources like power 🔋 and can be mapped to a block topology using the topology parameter. It's giving very main character energy, ngl.
• topology — (Optional) the name of a topology/block definition to map to this resource. Only valid for MODE_3 resources, so don't try it anywhere else 🙈 The HRes layers must have the same layout as the specified block topology. What does that buy you? The scheduler can simultaneously optimize both the HRes and block topology allocations. Slay ✨
• variables — (Optional) a list of name/value pairs that map arbitrary text strings to administratively-defined resource counts. Then your users can use those strings in job submissions (like --resources=power:full_node) instead of typing a numeric value, because numbers are lowkey exhausting. Each entry in the list contains:
  • name — the string alias for the value (e.g., "full_node").
  • value — the numeric resource count (e.g., 1000).
• layers — a list of layers that define the resource hierarchy. Each layer is a YAML object containing:
  • nodes — a list of node names or hostlist expressions that are part of this layer.
  • count — the total number of resources available in this specific layer.
  • base — (Optional) a list of name/value pairs describing non-job-related (static) resource consumption in this layer. This is particularly relevant for MODE_3. Each entry contains:
    • name — the name of the static resource consumer (e.g., "storage", "network1").
    • value — the numeric resource count this consumer uses.

🌈 EXAMPLE 🌈

Here's the whole thing in its natural habitat, verbatim, don't touch a character 💖

---
- resource: flat
  mode: MODE_2
  layers:
    - nodes:            # highest level
        - "node[01-32]"
      count: 24
    - nodes:            # middle levels
        - "node[01-16]"
      count: 16
    - nodes:
        - "node[17-32]"
      count: 16
    - nodes:            # lowest levels
        - "node[01-08]"
      count: 12
    - nodes:
        - "node[09-16]"
      count: 12
    - nodes:
        - "node[17-24]"
      count: 12
    - nodes:
        - "node[25-32]"
      count: 12
- resource: natural
  mode: MODE_1
  layers:
    - nodes:            # highest level
        - "node[01-32]"
      count: 50
    - nodes:            # lowest levels
        - "node[01-16]"
      count: 100
    - nodes:
        - "node[17-32]"
      count: 100
- resource: power
  mode: MODE_3
  topology: blok1
  variables:
    - name: full_node
      value: 1000
    - name: full_gpu_node
      value: 2000
  layers:
    - nodes:
        - "node[01-32]"
      count: 130000
      base:
        - name: acUnit1
          value: 10000
        - name: acUnit2
          value: 8000
    - nodes:
        - "node[01-16]"
      count: 60000
      base:
        - name: network1
          value: 3000
    - nodes:
        - "node[17-32]"
      count: 80000
      base:
        - name: network2
          value: 2000
    - nodes:
        - "node[01-08]"
      count: 40000
      base:
        - name: storage
          value: 5000
    - nodes:
        - "node[09-16]"
      count: 40000
    - nodes:
        - "node[17-24]"
      count: 40000
    - nodes:
        - "node[25-32]"
      count: 40000

💜 COPYING 💜

Copyright (C) 2025 SchedMD LLC.

This file is part of Slurm, a resource management program. For details, see https://slurm.schedmd.com/.

Slurm is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

Slurm is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

fr fr, read the license, it's not that long and it's literally protecting you 🫶

🦋 SEE ALSO 🦋

• slurm.conf(5)

and that's the whole page, bestie 💅✨ this was resources.yaml(5) from the Slurm 25.11 release, filed under Slurm Configuration File — go forth and layer your resources, you've got this 👑💖