Skip to content

Flaky ssh test_renderer_file: salt-ssh slsutil.renderer does not ship jinja imports; test depends on cache warmed by another test #69738

Description

@ggiesen

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

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions