* 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.
These aren't intended to function; they're here to allow the use of
file.recurse on the provider folder, without requiring the user
to provide pillar data for templates they're not using.
Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf
We don't want to stomp all over Salt's files, but we do want a pristine
starting point to lay down our managed config. So we use clean: True on the
file.recurse call, but we tell it to ignore files that start with an _
We have to rename the current config file (_defaults.conf) because it will be
ignored by the rule that ignores Salt's _* config files.
This also means we need to clean up old config files (_defaults.conf) and
restart the service if we cleaned it up.
If you are installing Salt via git/pip, the formula will try to overwrite your
install with packaged versions. This setting makes it possible to avoid that.
New versions of Salt put config files in /etc/salt/{minion,master}.d. We don't
want to erase them by using a clean: True on the file.recurse. This is a
backward incompatible change, but it's necessary to avoid deleting Salt config
files.
Resolves#104
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.
