Comments (12)
Interesting point.
I must admit that I always extend formulas by providing new sls under the same salt://
path.
With the following master
configuration:
fileserver_backend:
- roots
- gitfs
I can create /srv/salt/apache/www/foo.sls
and salt
will lookup that sls
with the following URL salt://apache/www/foo.sls
.
I'll make some try tomorrow and post my finding.
from apache-formula.
It took a little bit longer but I finally made little tests with relative imports and it's not trivial:
- using relative import of
map.jinja
in.sls
files is working (at least with my3001
test bed) - using relative import of files in
map.jinja
is not working because the relative pathes are expanded relatively to the.sls
file
So, salt 'testmachine2' state.show_sls foo.test-relative-import
works but salt 'testmachine2' state.show_sls foo.subcomponent.test-relative-import
does not.
To make my test, I created the following files:
foo/test-relavite-import.sls
{%- from "./map.jinja" import mapdata with context %} foo/test-relative-import: test.nop: - name: {{ mapdata }}
foo/subcomponent/test-relative-import.sls
{%- from "../map.jinja" import mapdata with context %} foo/subcomponent/test-relative-import: test.nop: - name: {{ mapdata }}
foo/map.jinja
{%- from "./test-relative-sub-import.jinja" import submapdata %} {%- set mapdata = submapdata %}
foo/test-relative-sub-import.jinja
{%- set submapdata = {'foo': 'bar'} %}
bar/test-relative-import.sls
{%- from "foo/map.jinja" import mapdata with context %} bar/test-relative-import: test.nop: - name: {{ mapdata }}
bar/subcomponent/test-relative-import.sls
{%- from "foo/map.jinja" import mapdata with context %} bar/subcomponent/test-relative-import: test.nop: - name: {{ mapdata }}
Here are the outputs:
salt 'testmachine2' state.show_sls foo.test-relative-import
testmachine2.example.net: ---------- foo/test: ---------- __env__: base __sls__: foo.test-relative-import test: |_ ---------- name: ---------- foo: bar - nop |_ ---------- order: 10000
salt 'testmachine2*' state.show_sls foo.subcomponent.test-relative-import
testmachine2.example.net: - Rendering SLS 'base:foo.subcomponent.test-relative-import' failed: Jinja error: ./test-relative-sub-import.jinja /var/cache/salt/minion/files/base/foo/map.jinja(1): --- {%- from "./test-relative-sub-import.jinja" import submapdata %} <====================== {%- set mapdata = submapdata %} --- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 400, in render_jinja_tmpl output = template.render(**decoded_context) File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render return original_render(self, *args, **kwargs) File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render return self.environment.handle_exception(exc_info, True) File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception reraise(exc_type, exc_value, tb) File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise raise value.with_traceback(tb) File "<template>", line 1, in top-level template code File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1073, in make_module return TemplateModule(self, self.new_context(vars, shared, locals)) File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1152, in __init__ body_stream = list(template.root_render_func(context)) File "/var/cache/salt/minion/files/base/foo/map.jinja", line 1, in top-level template code {%- from "./test-relative-sub-import.jinja" import submapdata %} File "/usr/lib/python3/dist-packages/salt/utils/jinja.py", line 204, in get_source raise TemplateNotFound(template) jinja2.exceptions.TemplateNotFound: ./test-relative-sub-import.jinja
salt 'testmachine2*' state.show_sls bar.test-relative-import
testmachine2.example.net: ---------- bar/test-relative-import: ---------- __env__: base __sls__: bar.test-relative-import test: |_ ---------- name: ---------- foo: bar - nop |_ ---------- order: 10000
salt 'testmachine2*' state.show_sls bar.subcomponent.test-relative-import
testmachine2.example.net: ---------- bar/subcomponent/test-relative-import: ---------- __env__: base __sls__: bar.subcomponent.test-relative-import test: |_ ---------- name: ---------- foo: bar - nop |_ ---------- order: 10000
This could be solved if we find a consistent way to find the path of the current included/imported file instead of current sls
file:
- having the real path of the imported
map.jinja
(in my test,tlpdir
is set tobar
when importing it inbar/test-relative-import.sls
usingwith context
but stayfoo
without thecontext
(now I wonder why we require thecontext
) - remove the trailing
/map.jinja
from that path - import relatively to that directory
Is there a way to achive this consistently across salt versions? I'm a bit lost about what is possible or not [1], [2] :-/
@myii: do you have any hint?
Regards.
from apache-formula.
I made a little test:
- take
openssh-formula
andopenntpd-formula
which have the_mapdata
verification - removing all the
with context
when importing frommap.jinja
- run the
bin/kitchen verify
for all supported platforms
The Inspec _mapdata_spec.rb
see no difference in the mapdata
contents…
The load with context is only useful when the imported .jinja
require to access variables set in the .sls
.
- without the
with context
,map.jinja
can't use thesomething
variable{%- set something = "this is something" %} {#- Get the `tplroot` from `tpldir` #} {%- set tplroot = tpldir.split('/')[0] %} {%- from tplroot ~ "/map.jinja" import mapdata %}
- with the
with context
,map.jinja
can use thesomething
variable{%- set something = "this is something" %} {#- Get the `tplroot` from `tpldir` #} {%- set tplroot = tpldir.split('/')[0] %} {%- from tplroot ~ "/map.jinja" import mapdata with context %}
I think we could say that map.jinja
must be loaded without with context
and then, map.jinja
lookup files relatively to it's tpldir
.
from apache-formula.
I made more tests and I think this solution may be interesting:
{#- Make sure `map.jinja` is imported without the context #}
{#- Import `with context` override the `tplfile` and `tpldir` variables #}
{%- if not tplfile.endswith("/map.jinja") %}
{{ raise("Import error: map.jinja must be imported without context. tplfile='" ~ tplfile ~ "'") }}
{%- endif %}
{#- `tplroot` is `tpldir`: the directory where is `map.jinja` #}
{%- set tplroot = tpldir %}
It's working with v5 map.jinja
for openvpn-formula for all kitchen supported platforms but not with relative imports like ../map.jinja
because tpldir
is ../
in this case.
This means that for the above example, I must remove all the with context
and replace ../map.jinja
by foo/map.jinja
in foo.subcomponent.test-relative-import
.
I could even add another test and raise in map.jinja
:
{%- if tplfile.startswith("../") %}
{{ raise("Import error: map.jinja must be imported with absolute path. tplfile='" ~ tplfile ~ "'") }}
{%- endif %}
This will permit to load map.jinja
of whatever formula from any other without troubles.
from apache-formula.
tpldir does not work with older versions.
for example it does not work Salt Version 3000.6
[ERROR ] Rendering exception occurred
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 169, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 404, in render_jinja_tmpl
buf=tmplstr)
SaltRenderError: Jinja variable 'tpldir' is undefined
/var/cache/salt/minion/files/base/apache/map.jinja(4):
---
# -*- coding: utf-8 -*-
# vim: ft=jinja
{%- set tplroot = tpldir.split('/')[0] %} <======================
{%- import_yaml tplroot ~ "/defaults.yaml" as default_settings %}
{%- import_yaml tplroot ~ "/osarchmap.yaml" as osarchmap %}
{%- import_yaml tplroot ~ "/osfamilymap.yaml" as osfamilymap %}
{%- import_yaml tplroot ~ "/osmap.yaml" as osmap %}
{%- import_yaml tplroot ~ "/osfingermap.yaml" as osfingermap %}
[...]
---
This is a big issue for non zero-day admins
from apache-formula.
tpldir does not work with older versions.
for example it does not work Salt Version 3000.6
Hello @kritzi-at, that's strange because I tested on all supported platforms with a test bed test-tplvars-formula
:
test-tplvars-formula/test-tplvars/test.sls
{%- from "test-tplvars/test-tplvars.jinja" import jinjafile, jinjadir %} test-tplvars-variable: file.managed: - name: /tmp/tplvars.txt - source: salt://test-tplvars/tplvars.txt.jinja - template: jinja - context: jinjafile: {{ jinjafile }} jinjadir: {{ jinjadir }}
test-tplvars-formula/test-tplvars/tplvars.txt.jinja
tplfile: {{ jinjafile }} tpldir: {{ jinjadir }}
test-tplvars-formula/test-tplvars/test-tplvars.jinja
{%- if not tplfile.endswith('/test-tplvars.jinja') %} {{ raise("Import error: map.jinja must be imported without context") }} {%- endif %} {%- set jinjafile = tplfile %} {%- set jinjadir = tpldir %}
test-tplvars-formula/test/integration/default/controls/tplvars.rb
# frozen_string_literal: true control "test-tplvars/test" do title 'check value of tplvars for imported jinja file' describe file('/tmp/tplvars.txt') do it { should be_file } its('content') { should include "tplfile: test-tplvars/test-tplvars.jinja" } its('content') { should include "tpldir: test-tplvars" } end end
I use kitchen files from template-formula with minor changes for this pseudo formula:
test-tplvars-formula/kitchen.yml file
# -*- coding: utf-8 -*-
# vim: ft=yaml
---
# For help on this file's format, see https://kitchen.ci/
driver:
name: docker
use_sudo: false
privileged: true
run_command: /lib/systemd/systemd
# Make sure the platforms listed below match up with
# the `env.matrix` instances defined in `.travis.yml`
platforms:
## SALT `tiamat`
- name: debian-10-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:debian-10
- name: debian-9-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:debian-9
- name: ubuntu-2004-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:ubuntu-20.04
- name: ubuntu-1804-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:ubuntu-18.04
- name: ubuntu-1604-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:ubuntu-16.04
- name: centos-8-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:centos-8
- name: centos-7-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:centos-7
- name: amazonlinux-2-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:amazonlinux-2
- name: oraclelinux-8-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:oraclelinux-8
- name: oraclelinux-7-tiamat-py3
driver:
image: saltimages/salt-tiamat-py3:oraclelinux-7
## SALT `master`
- name: debian-10-master-py3
driver:
image: saltimages/salt-master-py3:debian-10
- name: ubuntu-2004-master-py3
driver:
image: saltimages/salt-master-py3:ubuntu-20.04
- name: ubuntu-1804-master-py3
driver:
image: saltimages/salt-master-py3:ubuntu-18.04
- name: centos-8-master-py3
driver:
image: saltimages/salt-master-py3:centos-8
- name: fedora-32-master-py3
driver:
image: saltimages/salt-master-py3:fedora-32
- name: fedora-31-master-py3
driver:
image: saltimages/salt-master-py3:fedora-31
- name: opensuse-leap-152-master-py3
driver:
image: saltimages/salt-master-py3:opensuse-leap-15.2
run_command: /usr/lib/systemd/systemd
# Workaround to avoid intermittent failures on `opensuse-leap-15.2`:
# => SCP did not finish successfully (255): (Net::SCP::Error)
transport:
max_ssh_sessions: 1
- name: amazonlinux-2-master-py3
driver:
image: saltimages/salt-master-py3:amazonlinux-2
- name: gentoo-stage3-latest-master-py3
driver:
image: saltimages/salt-master-py3:gentoo-stage3-latest
run_command: /sbin/init
- name: gentoo-stage3-systemd-master-py3
driver:
image: saltimages/salt-master-py3:gentoo-stage3-systemd
## SALT `3001`
- name: debian-10-3001-py3
driver:
image: saltimages/salt-3001-py3:debian-10
- name: debian-9-3001-py3
driver:
image: saltimages/salt-3001-py3:debian-9
- name: ubuntu-2004-3001-py3
driver:
image: saltimages/salt-3001-py3:ubuntu-20.04
- name: ubuntu-1804-3001-py3
driver:
image: saltimages/salt-3001-py3:ubuntu-18.04
- name: centos-8-3001-py3
driver:
image: saltimages/salt-3001-py3:centos-8
- name: centos-7-3001-py3
driver:
image: saltimages/salt-3001-py3:centos-7
- name: fedora-32-3001-py3
driver:
image: saltimages/salt-3001-py3:fedora-32
- name: fedora-31-3001-py3
driver:
image: saltimages/salt-3001-py3:fedora-31
- name: opensuse-leap-152-3001-py3
driver:
image: saltimages/salt-3001-py3:opensuse-leap-15.2
run_command: /usr/lib/systemd/systemd
# Workaround to avoid intermittent failures on `opensuse-leap-15.2`:
# => SCP did not finish successfully (255): (Net::SCP::Error)
transport:
max_ssh_sessions: 1
- name: amazonlinux-2-3001-py3
driver:
image: saltimages/salt-3001-py3:amazonlinux-2
- name: oraclelinux-8-3001-py3
driver:
image: saltimages/salt-3001-py3:oraclelinux-8
- name: oraclelinux-7-3001-py3
driver:
image: saltimages/salt-3001-py3:oraclelinux-7
- name: gentoo-stage3-latest-3001-py3
driver:
image: saltimages/salt-3001-py3:gentoo-stage3-latest
run_command: /sbin/init
- name: gentoo-stage3-systemd-3001-py3
driver:
image: saltimages/salt-3001-py3:gentoo-stage3-systemd
## SALT `3000.3`
- name: debian-10-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:debian-10
- name: debian-9-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:debian-9
- name: ubuntu-1804-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:ubuntu-18.04
- name: centos-8-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:centos-8
- name: centos-7-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:centos-7
- name: fedora-31-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:fedora-31
- name: opensuse-leap-152-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:opensuse-leap-15.2
run_command: /usr/lib/systemd/systemd
# Workaround to avoid intermittent failures on `opensuse-leap-15.2`:
# => SCP did not finish successfully (255): (Net::SCP::Error)
transport:
max_ssh_sessions: 1
- name: amazonlinux-2-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:amazonlinux-2
- name: gentoo-stage3-latest-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:gentoo-stage3-latest
run_command: /sbin/init
- name: gentoo-stage3-systemd-3000-3-py3
driver:
image: saltimages/salt-3000.3-py3:gentoo-stage3-systemd
- name: ubuntu-1804-3000-3-py2
driver:
image: saltimages/salt-3000.3-py2:ubuntu-18.04
- name: ubuntu-1604-3000-3-py2
driver:
image: saltimages/salt-3000.3-py2:ubuntu-16.04
- name: arch-base-latest-3000-3-py2
driver:
image: saltimages/salt-3000.3-py2:arch-base-latest
run_command: /usr/lib/systemd/systemd
## SALT `2019.2`
- name: centos-6-2019-2-py2
driver:
image: saltimages/salt-2019.2-py2:centos-6
run_command: /sbin/init
- name: amazonlinux-1-2019-2-py2
driver:
image: saltimages/salt-2019.2-py2:amazonlinux-1
run_command: /sbin/init
provisioner:
name: salt_solo
log_level: debug
salt_install: none
require_chef: false
formula: test-tplvars
salt_copy_filter:
- .kitchen
- .git
verifier:
# https://www.inspec.io/
name: inspec
sudo: true
# cli, documentation, html, progress, json, json-min, json-rspec, junit
reporter:
- cli
suites:
- name: default
provisioner:
state_top:
base:
'*':
- test-tplvars.test
verifier:
inspec_tests:
- path: test/integration/default
After running ./bin/kitchen verify
, I have only errors for centos-6
and amazonlinux-1
which could no be created.
./bin/kitchen list
Instance Driver Provisioner Verifier Transport Last Action Last Error
default-debian-10-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-9-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-2004-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1804-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1604-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-8-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-7-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-amazonlinux-2-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-oraclelinux-8-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-oraclelinux-7-tiamat-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-10-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-2004-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1804-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-8-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-fedora-32-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-fedora-31-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-opensuse-leap-152-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-amazonlinux-2-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-latest-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-systemd-master-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-10-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-9-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-2004-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1804-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-8-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-7-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-fedora-32-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-fedora-31-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-opensuse-leap-152-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-amazonlinux-2-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-oraclelinux-8-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-oraclelinux-7-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-latest-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-systemd-3001-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-10-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-debian-9-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1804-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-8-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-7-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-fedora-31-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-opensuse-leap-152-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-amazonlinux-2-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-latest-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-gentoo-stage3-systemd-3000-3-py3 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1804-3000-3-py2 Docker SaltSolo Inspec Ssh Verified <None>
default-ubuntu-1604-3000-3-py2 Docker SaltSolo Inspec Ssh Verified <None>
default-arch-base-latest-3000-3-py2 Docker SaltSolo Inspec Ssh Verified <None>
default-centos-6-2019-2-py2 Docker SaltSolo Inspec Ssh <Not Created> Kitchen::ShellOut::ShellCommandFailed
default-amazonlinux-1-2019-2-py2 Docker SaltSolo Inspec Ssh <Not Created> Kitchen::ShellOut::ShellCommandFailed
from apache-formula.
I have now upgraded to salt-minion 3002.2
Error is still the same:
[ERROR ] Rendering exception occurred
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 498, in render_jinja_tmpl
output = template.render(**decoded_context)
File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 5, in top-level template code
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1073, in make_module
return TemplateModule(self, self.new_context(vars, shared, locals))
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1152, in __init__
body_stream = list(template.root_render_func(context))
File "/var/cache/salt/minion/files/base/apache/map.jinja", line 4, in top-level template code
{%- set tplroot = tpldir.split('/')[0] %}
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 430, in getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'tpldir' is undefined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 260, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 505, in render_jinja_tmpl
raise SaltRenderError("Jinja variable {}{}".format(exc, out), buf=tmplstr)
salt.exceptions.SaltRenderError: Jinja variable 'tpldir' is undefined
/var/cache/salt/minion/files/base/apache/map.jinja(4):
---
# -*- coding: utf-8 -*-
# vim: ft=jinja
{%- set tplroot = tpldir.split('/')[0] %} <======================
{%- import_yaml tplroot ~ "/defaults.yaml" as default_settings %}
{%- import_yaml tplroot ~ "/osarchmap.yaml" as osarchmap %}
{%- import_yaml tplroot ~ "/osfamilymap.yaml" as osfamilymap %}
{%- import_yaml tplroot ~ "/osmap.yaml" as osmap %}
{%- import_yaml tplroot ~ "/osfingermap.yaml" as osfingermap %}
[...]
---
When i use slsutil.renderer the tpldir seems to be defined, but not as expected:
# salt-call slsutil.renderer salt://apache/map.jinja
[ERROR ] Rendering exception occurred
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 498, in render_jinja_tmpl
output = template.render(**decoded_context)
File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 5, in top-level template code
File "/usr/lib/python3/dist-packages/salt/utils/jinja.py", line 198, in get_source
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: ./defaults.yaml
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 260, in render_tmpl
output = render_str(tmplstr, context, tmplpath)
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 543, in render_jinja_tmpl
"Jinja error: {}{}".format(exc, out), line, tmplstr, trace=tracestr
salt.exceptions.SaltRenderError: Jinja error: ./defaults.yaml
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/salt/utils/templates.py", line 498, in render_jinja_tmpl
output = template.render(**decoded_context)
File "/usr/lib/python3/dist-packages/jinja2/asyncsupport.py", line 76, in render
return original_render(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
File "<template>", line 5, in top-level template code
File "/usr/lib/python3/dist-packages/salt/utils/jinja.py", line 198, in get_source
raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: ./defaults.yaml
; line 5
---
# -*- coding: utf-8 -*-
# vim: ft=jinja
{%- set tplroot = tpldir.split('/')[0] %}
{%- import_yaml tplroot ~ "/defaults.yaml" as default_settings %} <======================
{%- import_yaml tplroot ~ "/osarchmap.yaml" as osarchmap %}
{%- import_yaml tplroot ~ "/osfamilymap.yaml" as osfamilymap %}
{%- import_yaml tplroot ~ "/osmap.yaml" as osmap %}
{%- import_yaml tplroot ~ "/osfingermap.yaml" as osfingermap %}
{%- import_yaml tplroot ~ "/oscodenamemap.yaml" as oscodename %}
[...]
---
from apache-formula.
Hello @kritzi-at, can you try a salt 'minion' state.apply test-tplvars.test
with my tests files?
Note that apache-formula
is working on different environment as you can see in the last pipeline run, even on a 2017.7.
from apache-formula.
Hello @baby-gnu
Test script works fine on Ubuntu with minion 3002.2
# salt-call state.apply test-tplvars.test
local:
----------
ID: test-tplvars-variable
Function: file.managed
Name: /tmp/tplvars.txt
Result: True
Comment: File /tmp/tplvars.txt updated
Started: 16:05:23.627108
Duration: 75.168 ms
Changes:
----------
diff:
New file
mode:
0644
Summary for local
------------
Succeeded: 1 (changed=1)
Failed: 0
------------
Total states run: 1
Total run time: 75.168 ms
# cat /tmp/tplvars.txt
tplfile: test-tplvars/test-tplvars.jinja
tpldir: test-tplvars
and on CentOS with minion 3000.6
# salt-call state.apply test-tplvars.test
local:
Name: /tmp/tplvars.txt - Function: file.managed - Result: Changed Started: - 16:05:00.786759 Duration: 74.754 ms
Summary for local
------------
Succeeded: 1 (changed=1)
Failed: 0
------------
Total states run: 1
Total run time: 74.754 ms
# cat /tmp/tplvars.txt
tplfile: test-tplvars/test-tplvars.jinja
tpldir: test-tplvars
from apache-formula.
Thanks @kritzi-at, so now I'm wondering why applying apache-formula
is not working for you.
Can you explain a little your setup and how you run the formula?
from apache-formula.
Hello @baby-gnu, i found the issue.
The problem was related to the template_file i set in the pillar.
The template file was custom made and included apache/map.jinja without using it.
Removing the line fixed everything.
from apache-formula.
More tests to see the differences between with context
and without context
: https://gist.github.com/baby-gnu/c8c6d1b423ac64b88011ffba2b4e884d
So, only tplfile
is different and with context
the tplroot
variable is propagated from the .sls
to the imported .jinja
file.
from apache-formula.
Related Issues (20)
- Default log formats doesn't use IP from mod remoteip in debian
- [BUG] apache.vhost.cleanup fails if apache is not yet installed HOT 2
- [FEATURE] support mod_md
- In Debian apache.config plays two opposite actions HOT 1
- A recursive requisite was found in apache.config.modules.mod_security
- [BUG] apache.vhosts.standard (and potentially others) generate MemoryError HOT 9
- [BUG] apache.config.vhosts.standard: mapping error when "enabled: false" HOT 3
- yaml syntax error in mod_pagespeed.sls HOT 1
- [BUG] syntax error near "module;" in apache/config/register_site.sls line 66 HOT 1
- [BUG] apache.config.modules.mod_wsgi fails, pkg: apache not found HOT 2
- [BUG] On CentOS 7, enabled modules are reported as changed on every highstate HOT 1
- [BUG] apache.config.vhosts.cleanup now remove the service HOT 3
- [BUG] in vhosts/standard.sls the map.pop affects the apache variable as well because it is a reference, not a copy HOT 3
- [BUG] ssl.conf should never be removed - should always be managed
- [BUG] vhost proxy.tmpl doesn' add DocumentRoot
- [BUG] ID apache-service-running in SLS apache.service.running is not a dictionary
- [FEATURE] Add SSLCACertificate
- [FEATURE] handle multiple CustomLog directives
- [BUG] apache.clean removed too much files, breaking installation after reinstall
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from apache-formula.