salt: forumla's map.jinja not found in jinja-template-files on salt-ssh
Expected Behavior
the forumla’s file-generation by jinja-template should load map.jinja also on salt-ssh. this formula works with salt minion state.highstate like a charm, but not with salt-ssh minion state.highstate
Actual Behavior
when performing a state.highstate via salt-ssh i get the following error-msg: (see bottom)
Steps to Reproduce Issue
- create a simple formula with map.jinja
- add file generation by jinja (file.managed: - source: salt://…/file.jinja - template: jinja) to this formula
- import the map.jinja to this file.jinja-template with
{% from ... import ... %} - try to provision this formula to a minion with salt-ssh --> you will get the error from above
Versions Report
Salt Version:
Salt: 2015.8.7
Dependency Versions:
Jinja2: 2.7.2
M2Crypto: Not Installed
Mako: 0.9.1
PyYAML: 3.10
PyZMQ: 14.0.1
Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
RAET: Not Installed
Tornado: 4.2.1
ZMQ: 4.0.4
cffi: Not Installed
cherrypy: Not Installed
dateutil: 1.5
gitdb: 0.5.4
gitpython: 0.3.2 RC1
ioflo: Not Installed
libgit2: Not Installed
libnacl: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.3.0
mysql-python: 1.2.3
pycparser: Not Installed
pycrypto: 2.6.1
pygit2: Not Installed
python-gnupg: Not Installed
smmap: 0.8.2
timelib: Not Installed
System Versions:
dist: Ubuntu 14.04 trusty
machine: x86_64
release: 3.13.0-71-generic
system: Ubuntu 14.04 trusty
Relevant Logs, Configs, or States
Error-Message: `Unable to manage file: Jinja error: jinjatest/map.jinja
Traceback (most recent call last):
File "/tmp/.root_09032a_salt/salt/utils/templates.py", line 366, in render_jinja_tmpl
output = template.render(**decoded_context)
File "/tmp/.root_09032a_salt/jinja2/environment.py", line 969, in render
return self.environment.handle_exception(exc_info, True)
File "/tmp/.root_09032a_salt/jinja2/environment.py", line 742, in handle_exception
reraise(exc_type, exc_value, tb)
File "<template>", line 1, in top-level template code
File "/tmp/.root_09032a_salt/salt/utils/jinja.py", line 144, in get_source
raise TemplateNotFound(template)
TemplateNotFound: jinjatest/map.jinja
; line 1
---
{% from "jinjatest/map.jinja" import jinjatest with context %} <======================
hello {{ jinjatest.name }}
you are {{ jinjatest.age }} old
Traceback (most recent call last):
File "/tmp/.root_09032a_salt/salt/utils/templates.py", line 366, in render_jinja_tmpl
[...]`
here is the simple-test-formula: salt-jinjatest.zip
About this issue
- Original URL
- State: open
- Created 8 years ago
- Reactions: 10
- Comments: 32 (17 by maintainers)
Commits related to this issue
- Modified formula to work more seamlessly with salt-ssh. See: https://github.com/saltstack/salt/issues/31531 — committed to spoage/vhusbd-formula by deleted user 7 years ago
I did more tests with 6 machines with different versions of
salt-sshfrom3002.7to3004.Each machine has the following setup:
/root/.salt/Saltfile/root/.salt/master/root/.salt/roster/root/.salt/srv/salt/test-import/init.sls/root/.salt/srv/salt/test-import/absolute.sls/root/.salt/srv/salt/test-import/relative.slsThen, I run the
state.show_slsfrom all machines, I include a--versions-reportto make things clear.This works fine on
3002.7and fails on all versions starting with3003.salt-ssh 'testmachine*' cmd.run 'salt-ssh --versions-report; salt-ssh -l critical testmachine6 state.show_sls test-import'This was not an issue in salt-2019.2.0-1 but since updating to salt-3000.2-1 it has become so.
I made an ugly patch that seemingly fixes this issue by packing the whole
salt://directory into the salt-ssh state tarball:To activate it add
--extra-filerefs 'salt://'command line option tosalt-ssh. Also it is possible to do the same through/etc/salt/masterconfig snippet:@Ismail-AlJubbah Certainly!
The know workaround is using extra_filerefs. The salt-ssh code doesn’t pick up files that aren’t referenced by include or source. The import doesn’t count. I have tried a system of having a state to source the map.jinja in cases of salt-ssh, but it proved to be more work than using the extra_filerefs method. See #9878 for history.