What happened?
tests/pytests/integration/ssh/test_slsutil.py::test_renderer_file flakes on the "Rocky Linux 9 / Ubuntu integration" jobs, failing with:
salt.exceptions.SaltRenderError: Jinja error: map.jinja
jinja2.exceptions.TemplateNotFound: map.jinja
{%- from "map.jinja" import abc with context %}
Root cause (reproduced deterministically)
The test runs salt-ssh localhost slsutil.renderer salt://test.sls, where test.sls does {% from "map.jinja" import abc %}. Over salt-ssh, slsutil.renderer fetches the requested file (test.sls) but does not ship that file's jinja-imported dependencies (map.jinja) to the target. Only a state run (state.apply/state.sls) triggers salt-ssh's full state-tree sync to the target's file cache.
So the render finds test.sls but not map.jinja, and SaltCacheLoader.cache_file("map.jinja") on the target comes back empty (confirmed: cp.cache_file salt://map.jinja over salt-ssh returns False in isolation). The test only passes when an earlier test in the same session already ran a state command that synced map.jinja into the shared salt-ssh target cache -- hence flaky (ordering-dependent) in CI and deterministic when run in isolation.
Reproduced locally against 3006.x with the pinned test stack: test_renderer_file fails 3/3 in isolation, and passes as soon as a tree-syncing state call runs first (state.apply test test=True warms the cache, then slsutil.renderer succeeds). All sibling salt-ssh slsutil tests (which do not use jinja imports) pass unconditionally.
Two fixable layers
- Test isolation (this issue): the renderer tests should not depend on another test having warmed the salt-ssh target cache; prime it deterministically in the fixture.
- Underlying salt-ssh behaviour (separate):
slsutil.renderer salt://<file> over salt-ssh does not make the file's jinja imports available on the target. Whether that should be supported is a broader salt-ssh question; filing the test-isolation fix first.
Type of salt install
Official rpm
Major version
3006.x
What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)
rockylinux-9
salt --versions-report output
Reproduced in CI (3006.x) and locally against the pinned py3.11 test stack.
What happened?
tests/pytests/integration/ssh/test_slsutil.py::test_renderer_fileflakes on the "Rocky Linux 9 / Ubuntu integration" jobs, failing with:Root cause (reproduced deterministically)
The test runs
salt-ssh localhost slsutil.renderer salt://test.sls, wheretest.slsdoes{% from "map.jinja" import abc %}. Over salt-ssh,slsutil.rendererfetches the requested file (test.sls) but does not ship that file's jinja-imported dependencies (map.jinja) to the target. Only a state run (state.apply/state.sls) triggers salt-ssh's full state-tree sync to the target's file cache.So the render finds
test.slsbut notmap.jinja, andSaltCacheLoader.cache_file("map.jinja")on the target comes back empty (confirmed:cp.cache_file salt://map.jinjaover salt-ssh returnsFalsein isolation). The test only passes when an earlier test in the same session already ran a state command that syncedmap.jinjainto the shared salt-ssh target cache -- hence flaky (ordering-dependent) in CI and deterministic when run in isolation.Reproduced locally against 3006.x with the pinned test stack:
test_renderer_filefails 3/3 in isolation, and passes as soon as a tree-syncing state call runs first (state.apply test test=Truewarms the cache, thenslsutil.renderersucceeds). All sibling salt-ssh slsutil tests (which do not use jinja imports) pass unconditionally.Two fixable layers
slsutil.renderer salt://<file>over salt-ssh does not make the file's jinja imports available on the target. Whether that should be supported is a broader salt-ssh question; filing the test-isolation fix first.Type of salt install
Official rpm
Major version
3006.x
What supported OS are you seeing the problem on? Can select multiple. (If bug appears on an unsupported OS, please open a GitHub Discussion instead)
rockylinux-9
salt --versions-report output