SaltStack provides "versioned" repositories, this commit add a way
to set which release of salt to use.
It adds a pillar "salt:release" which can be set to a specific release
(ex: 2016.11). This release is then used to configure properly the
repositories URLs for Debian/Ubuntu/RedHat.
The default behavior is to point to 'latest', retaining the previous
behavior if the "salt:release" pillar is not set.
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.
Since the set of directories is known, just iterate of its well known
names directly. Make sure files are dumped after `file.recurse` to avoid
deletion/creation cycles when applying highstate.
Also apply permissions on cloud.providers.d after all creations steps
are done.
!! 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
Some Unix variants name GID 0 "wheel". Unfortunately, one cannot
specify this group by ID, because Python conflates integer 0 with
boolean False, nor can one specify this group using the string '0',
because of assumptions in the Salt or Python codebases regarding group
names.
The salt-api service is configured using the master config files but is
not restarted when the master is restarted. We need the salt-api service
to watch the master config files to ensure that any config changes are
picked up.
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)