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.
This state enables the official saltstack package repository in order to
always benefit from the latest version. This state currently only works on
Debian and Ubuntu, and aims to implement the installation recommendations
of the official documentation:
http://docs.saltstack.com/en/latest/topics/installation/index.html
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.