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`.