Skip to content

[3006.x] Fix salt-ssh Jinja TemplateNotFound on map.jinja imports#69596

Open
dwoz wants to merge 1 commit into
saltstack:3006.xfrom
dwoz:dwoz/fix/issue-31531-jinja-cachedir-backport
Open

[3006.x] Fix salt-ssh Jinja TemplateNotFound on map.jinja imports#69596
dwoz wants to merge 1 commit into
saltstack:3006.xfrom
dwoz:dwoz/fix/issue-31531-jinja-cachedir-backport

Conversation

@dwoz

@dwoz dwoz commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Backports the salt/utils/jinja.py hunk from commit 481bd7a6a72 to 3006.x.

SaltCacheLoader built its searchpath from opts["cachedir"]. Under
salt-ssh, opts["cachedir"] points at the thin minion's remote path on the
SSH target, while the master-side fileclient caches requested files under
opts["_caller_cachedir"] (the master's cachedir). A Jinja import like
{% from "formula/map.jinja" import x with context %} therefore raised
TemplateNotFound: the file existed in the master cache, but the loader
looked in the (empty) thin path.

This change makes SaltCacheLoader.__init__ prefer
opts["_caller_cachedir"] when present, so Jinja imports resolve against
the master's cache dir. The _caller_cachedir opt is already populated on
3006.x by salt/client/ssh/__init__.py (lines ~1206-1209) — only the
consumer side was missing.

What issues does this PR fix or reference?

Fixes: #31531

Background

#31531 was opened in 2016 and closed on 2026-06-29 citing PR #65517, but
that PR's body says "Helps with: 31531" (not "Fixes") and does not patch
SaltCacheLoader.searchpath. The actual fix is commit 481bd7a6a72 (Apr
2026), shipped in v3007.14 and v3008.0+. That commit was never backported
to 3006.x, so the bug still reproduces there.

Library-level repro on each branch (constructing SaltCacheLoader with
opts mimicking the salt-ssh master-side wrapper call):

branch result
3006.x (pre-patch) FAIL — TemplateNotFound: jinjatest/map.jinja
3006.x (this PR) PASS
3007.x PASS (already has 481bd7a6a72)
3008.x PASS (already has 481bd7a6a72)
master PASS (already has 481bd7a6a72)

Why only the jinja.py hunk?

Commit 481bd7a6a72 also restored @pytest.mark.timeout(300) markers on
some salt-ssh integration tests and bumped the salt_ssh_cli factory
timeout in tests/pytests/integration/conftest.py from 180s to 300s.
Those hunks address 3007.x/3008.x-specific test regressions from a
parallel SSH ThreadPool revert and have no analogue on 3006.x — pulling
them in would be drive-by noise and would not apply cleanly. Only the
single 5-line SaltCacheLoader.__init__ change is relevant here.

Regression test

tests/pytests/unit/utils/jinja/test_salt_cache_loader.py::test_searchpath_uses_caller_cachedir
asserts that when opts["_caller_cachedir"] is set the loader's
searchpath is built from it instead of opts["cachedir"]. Verified
locally: test FAILS without the patch, PASSES with it. All 19 tests in
test_salt_cache_loader.py pass.

Merge requirements satisfied?

  • Tests written (regression test added)
  • Changelog (changelog/31531.fixed.md)
  • No drive-by changes

Commits signed with GPG?

Yes

Backport of 481bd7a (3007.x/3008.x) to 3006.x.

SaltCacheLoader built its searchpath from opts["cachedir"]. Under
salt-ssh, opts["cachedir"] points at the thin minion's remote path on
the SSH target, while the master-side fileclient caches requested files
under opts["_caller_cachedir"] (the master's cachedir). A Jinja import
like {% from "formula/map.jinja" import x with context %} therefore
raised TemplateNotFound: the file existed in the master cache, but the
loader looked in the (empty) thin path.

Prefer opts["_caller_cachedir"] when present so Jinja imports resolve
against the master's cache dir. opts["_caller_cachedir"] is already
populated on 3006.x by salt/client/ssh/__init__.py; only the consumer
was missing.

Only the salt/utils/jinja.py hunk from 481bd7a is backported; the
test-timeout hunks in that commit are 3007.x/3008.x-only.

Fixes: saltstack#31531
@dwoz dwoz requested a review from a team as a code owner June 29, 2026 04:12
@dwoz dwoz added this to the Sulphur v3006.27 milestone Jun 29, 2026
@dwoz dwoz added the test:full Run the full test suite label Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test:full Run the full test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant