Feature Request: make _has_memory_headroom function more configurable
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
Discussed in https://github.com/saltstack/salt/discussions/69732
Originally posted by do3meli July 6, 2026
The function _has_memory_headroom is actually checking if the system has less than 95% of the total memory available free. If so it will return true and otherwise it will return false:
https://github.com/saltstack/salt/blob/24a4cfac284251d0da87c308b78e73d60b5f4d54/salt/minion.py#L2110-L2116
The problem with this is, that salt-minion jobs get queued up on nodes that have a huge amount of memory still free. Let's say you have 2TB memory nodes. 5% memory headroom on such a system would be 102.4 GB. I guess that should be more than enough for salt ;-) Therefore i suggest to have the following to adjustments:
- make the memory limit in percent configurable: instead of using 95 as hardcoded in the code substitute this with a variable that can be configured via minion config.
- enhance the condition in a way that it is also possible to use a pre defined (via config of minion) number of memory that needs to be available (for example 5 GB). If that is set, i guess it would be preferred over the percent that is defined.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the referenced _has_memory_headroom function in salt/minion.py at lines 2110-2116, then read discussion 69732 for the proposed behavior. Identify the minion configuration path for both percentage and absolute memory thresholds, with the absolute threshold taking precedence when set. Done means both options are configurable and the existing headroom behavior remains covered by relevant tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100