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)
The salt-cloud packages automatically pull in the pycrypto and libcloud
dependencies for RedHat and Debian (at least when using the SaltStack
repos), so it doesn't really make sense to install these dependencies
using pip. By default we no longer use pip, but the old behaviour can be
restored by setting 'salt:use_pip' to True in the pillar.
There could probably be a case made for removing the pip stuff
altogether, but we will leave it in for the time being to preserve some
backwards compatibility.
Rasbian reports back the following grain values:
local:
----------
os:
Raspbian
os_family:
Debian
osarch:
armhf
osmajorrelease:
8
osrelease:
8.0
Ubuntu reports back the following grain values:
local:
----------
os:
Ubuntu
os_family:
Debian
osarch:
amd64
osmajorrelease:
14
osrelease:
14.04
For Raspbian the osarch needed to be changed from other Debain os_family
distributions.
For Ubuntu the osrelease value is needed instead of osmajorrelease as other
Debian os_family distributions.
Part of #180
repo.saltstack.com handles all currently supported Debian releases as well
as all supported Ubuntu releases so this change should be fine.
Part of #180.
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.
Without this change, importing map.jinja in config files (as opposed to
SLS files) causes a rendering error because `slspath` isn't defined.
The `salt_settings.key_url` variable gets used only in
`salt/pkgrepo/debian/init.sls`.
Jinja macros are not actually functions. The only thing they can return
is a string. In order to return structured data, the callee must
serialize it, and the caller must deserialize it. This state formula
uses YAML as the intermediary, hence the occurrence of both the
`|yaml` (callee) and `|load_yaml` (caller) filters in its code.
The post-render "mapping values are not allowed here" error in
*salt/formulas.sls* or the broken rendering of
*salt/files/master.d/f_defaults.conf* happens because invocations of the
`formulas_git_opt` macro in several Jinja `set` statements do not get
deserialized, resulting in the trailing newline followed by three dot
characters (`...`), which YAML uses to signal the end of a document.
Correcting these rendering errors requires adding the necessary
deserialization code at those locations (i.e., filtering the macro call
through `|load_yaml`).
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 change tweaks the GitPython package installation state to support
alternate package names (on FreeBSD, it's called "py27-GitPython").
Also, on FreeBSD salt-ssh is included in the "py27-salt" package by
default, requiring an update to `distro_map`.
The syndic service was depending upon itself, which caused the salt run
to fail. This commit fixes that by depending on the salt-master service
rather than the salt-syndic service. I also made it more general by
using IDs to specify the provider rather than the name, which is a bit
less reliable.
* Install pygit from package
* Add Official Salt ZeroMQ 4 COPR repository
Note that Salt itself is assumed to already to be available to the system via yum, via EPEL for example
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
As mentioned in issue #118, provider files may contain passwords
or API keys and should be restricted. Profiles/maps are probably
OK with the defaults.
