If a rule is already in the table but at a different position, there
would be several plausible things to do: either add it to the specified
position (duplicating the existing rule), or treat the pre-existing copy
as sufficient even though it is not in the specifed position, or raise an
error. In fact Salt treats the pre-existing copy as sufficient.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Debian's iptables package provides mechanism but not policy, and in
particular doesn't load rules during system startup. There are
several packages that can provide that, but the only one Salt supports
appears to be iptables-persistent.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The examples mention this, but the reference documentation did not,
and it isn't obvious from the example that minimal installations of
some operating systems (in particular Debian) don't have all the
necessary packages to make it effective, even if iptables itself is
installed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This provides both the line number on which the error occurred in the
Jinja template, and also several lines of context around the error in
the Jinja template source.
The one caveat to this change is that if paired with jinja2<2.11 it
could possibly report incorrect line numbers for some errors. This was
fixed in https://github.com/pallets/jinja/pull/1109
Traces/errors before were vague and ambiguous:
File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 387, in render_jinja_tmpl
buf=tmplstr)
SaltRenderError: Jinja variable 'str object' has no attribute 'items'
This gives a line number and multiple lines of context:
File "/usr/lib/python2.7/dist-packages/salt/utils/templates.py", line 387, in render_jinja_tmpl
tmplstr)
SaltRenderError: Jinja variable 'str object' has no attribute 'items'; line 5
---
# {{ salt.pillar.get('managed_by_salt_message', '') }}
# salt template: {{ source }}
{%- for section in sections %}
{%- for name, config in section.items() %} <======================
[{{ name }}]
{%- for line in config %}
{{ line }}
{%- endfor %}
{%- endfor %}
[...]
---
Signed-off-by: Joe Groocock <jgroocock@cloudflare.com>
* a "filesystem.present" or "volume.present" state that specified no
properties would fail because it would execute "zfs get" with no property
argument. Fix this (and improve performance too) by skipping the "zfs
get" if the user does not request any property values.
* A "volume.present" state that specified volume_size but no properties
would fail to check the volsize.
Also, make the properties argument of _dataset_properties a mandatory
argument rather than a keyword argument. All callers already specify this
argument, making the default value a red herring.
