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