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)
This avoids problems when values are strings containing colons. And it
mimicks what was already done for the salt-minion's configuration file.
Fixes#233.
With a simple pillar like this::
$ sudo salt-call --config-dir /srv/etc/bootstrap --pillar-root /srv/pillar pillar.get salt:pillar_roots
local:
----------
base:
- /srv/pillar
This was generated in /etc/salt/master.d/f_defaults.conf::
# highstate format, and is generally just key/value pairs.
pillar_roots:base:- /srv/pillar
#
Resulting in parse errors by salt::
$ sudo salt '*' state.highstate
[ERROR ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
in "<string>", line 531, column 1:
pillar_roots:base:- /srv/pillar
^
could not found expected ':'
in "<string>", line 532, column 1:
#
^
[ERROR ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
in "<string>", line 531, column 1:
pillar_roots:base:- /srv/pillar
^
could not found expected ':'
in "<string>", line 532, column 1:
#
^
This patch will fix it as such::
ID: salt-master
Function: file.recurse
Name: /etc/salt/master.d
Result: True
Comment: Recursively updated /etc/salt/master.d
Started: 11:37:12.946823
Duration: 6255.296 ms
Changes:
----------
/etc/salt/master.d/f_defaults.conf:
----------
diff:
---
+++
@@ -528,7 +528,9 @@
# Pillar is laid out in the same fashion as the file server, with environments,
# a top file and sls files. However, pillar data does not need to be in the
# highstate format, and is generally just key/value pairs.
-pillar_roots:base:- /srv/pillar
+pillar_roots:
+ base:
+ - /srv/pillar
#
Resulting in::
# highstate format, and is generally just key/value pairs.
pillar_roots:
base:
- /srv/pillar
#
This commit fixes how `pillar_roots` are generated and after this fix the
generated configuration does not contain any unnecessary new lines:
```yaml
pillar_roots:
base:
/srv/salt/dir1
dev:
/srv/salt/dir2
/srv/salt/dir3
locale:
/srv/salt/dir4
```
Before this commit the pillar_roots in `f_defaults.conf` for master would be
generated with a lot of empty lines in between directories, like this:
```yaml
pillar_roots:
base:
/srv/salt/dir1
dev:
/srv/salt/dir2
/srv/salt/dir3
local:
/srv/salt/dir4
```
The minion configuration is not affected and renders fine.
The user will already have it's /etc/salt/minion file, so it doesn't need all this info, and it makes easier to know what has been generated and what not
These aren't intended to function; they're here to allow the use of
file.recurse on the provider folder, without requiring the user
to provide pillar data for templates they're not using.
Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf
We don't want to stomp all over Salt's files, but we do want a pristine
starting point to lay down our managed config. So we use clean: True on the
file.recurse call, but we tell it to ignore files that start with an _
We have to rename the current config file (_defaults.conf) because it will be
ignored by the rule that ignores Salt's _* config files.
This also means we need to clean up old config files (_defaults.conf) and
restart the service if we cleaned it up.
If those options are set in pillar data, the jinja template
salt/files/master.d/_defaults.conf would fail to compile trying to
evaluate non-existing variables.
Replace those variables with the corresponding dictionnary entries.
Most include do not expect salt to be something else than the usual salt
variable giving access to all the salt modules. Instead we use cfg_salt.
And for consistency we rename the master/minion variables to
cfg_master/cfg_minion too.
This commit also provides a more concrete example of a 'host' to
be saltified. Users can do
salt-cloud -p make_salty someinstance
or
salt-cloud -m /etc/salt/cloud.maps.d/foo.conf
Either which way the online docs should really be updated with more
concrete examples.
In Python 3, dict.items() is already an iterator while dict.iteritems() no
longer exits. In Python 2, dict.items() is not an iterator but it works
and the small performance hit doesn't really matter for the salt config
pillar data which is really small.
Gitfs for the minion is possible with salt 2014.7
Updated config _defaults.conf and pillar with example
Tested it on Archlinux with salt-call --local state.highstate
Commit 2b51a6f0c3 introduced options for gitfs_remotes in a pillar by using a jinja test to see if a parameter is a mapping (dict etc.). This feature however is only available in jinja 2.6 or newer (see http://jinja.pocoo.org/docs/dev/templates/#mapping).
Although this version of Jinja is available on Ubuntu, other OS / package managers do provide older versions (2.2.1 in RedHat 6).
This change makes use of the "iterable" test which should do the exact same thing.
