I use Salt environments to provide each of my team mates the ability to develop
and test their Salt changes. And I've found that when we run this formula from
our environments against our salt-master, comments in some files change. For us
this represents an unwanted and unplanned change. I understand the intention -
to identify how or why the file changed, but I firmly believe that we should
be able to run highstsate with test=True and only see intended changes. Here's
an example:
ID: salt-cloud-providers
Function: file.recurse
Name: /etc/salt/cloud.providers.d
Result: None
Comment: #### /etc/salt/cloud.providers.d/saltify.conf ####
The file /etc/salt/cloud.providers.d/saltify.conf is set to be changed
Started: 20:01:28.586441
Duration: 75.185 ms
Changes:
----------
/etc/salt/cloud.providers.d/saltify.conf:
----------
diff:
---
+++
@@ -1,4 +1,4 @@
-# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=myenv
+# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=dev
saltify:
provider: saltify
As discussed in PR#305, these are defaults that even if they are
configurable as probably not suited to a majority of users and causes
delete/add output on highstate of user of the formula choses to use
the same file name.
!! Not tested with an actual !!
!! configured `ext_pillar` yet !!
- jinja on RHEL/CentOS 6 has no 'mapping'
test (see salt-formula issue #193)
- {% do ... %} allows no assignment, only
function calls
- of course, `type(foo) is dict` doesn't
work because it's no jinja test
- maybe `.isinstance()` would be nicer/more
reliable
Using the old salt.engines pillar and merging it with the new
salt.[master|minion].engines pillar.
This way, it doesn't break previous behavior and permits to define
common engines on master and minion.
In the merge, the salt.[master|minion].engines pillar takes precedence
if conflict as it's the more specific pillar.
the engines are now configured using the following pillars:
* salt.master.engines
* salt.minion.engines
instead of a global salt.engines pillar.
Note: the pillar.example provided seems to assume this behaviour.
(the pillar is salt.master.engines.slack and not salt.engines.slack)
