I use Salt environments to provide each of my team mates the ability to develop
and test their Salt changes. And I've found that when we run this formula from
our environments against our salt-master, comments in some files change. For us
this represents an unwanted and unplanned change. I understand the intention -
to identify how or why the file changed, but I firmly believe that we should
be able to run highstsate with test=True and only see intended changes. Here's
an example:
ID: salt-cloud-providers
Function: file.recurse
Name: /etc/salt/cloud.providers.d
Result: None
Comment: #### /etc/salt/cloud.providers.d/saltify.conf ####
The file /etc/salt/cloud.providers.d/saltify.conf is set to be changed
Started: 20:01:28.586441
Duration: 75.185 ms
Changes:
----------
/etc/salt/cloud.providers.d/saltify.conf:
----------
diff:
---
+++
@@ -1,4 +1,4 @@
-# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=myenv
+# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=dev
saltify:
provider: saltify
SaltStack provides "versioned" repositories, this commit add a way
to set which release of salt to use.
It adds a pillar "salt:release" which can be set to a specific release
(ex: 2016.11). This release is then used to configure properly the
repositories URLs for Debian/Ubuntu/RedHat.
The default behavior is to point to 'latest', retaining the previous
behavior if the "salt:release" pillar is not set.
As discussed in PR#305, these are defaults that even if they are
configurable as probably not suited to a majority of users and causes
delete/add output on highstate of user of the formula choses to use
the same file name.
Since the set of directories is known, just iterate of its well known
names directly. Make sure files are dumped after `file.recurse` to avoid
deletion/creation cycles when applying highstate.
Also apply permissions on cloud.providers.d after all creations steps
are done.
!! Not tested with an actual !!
!! configured `ext_pillar` yet !!
- jinja on RHEL/CentOS 6 has no 'mapping'
test (see salt-formula issue #193)
- {% do ... %} allows no assignment, only
function calls
- of course, `type(foo) is dict` doesn't
work because it's no jinja test
- maybe `.isinstance()` would be nicer/more
reliable
Some Unix variants name GID 0 "wheel". Unfortunately, one cannot
specify this group by ID, because Python conflates integer 0 with
boolean False, nor can one specify this group using the string '0',
because of assumptions in the Salt or Python codebases regarding group
names.
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.
