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
#
