FAQ
Hi,

What I'd like to have, is a very simplistic/straightforward usage of salt.
There are a few constraints:
  - Both states and pillars should live in the same git repo
  - It should always be possible to run highstate on the master branch (base)
  - Very clear (simple) configuration
  - Different management domains with different rule-sets

What I've come up with is depicted below.

/etc/salt/master:
fileserver_backend:
   - git
gitfs_remotes:
   - https://<user>:<pass>@gitlab/salt-master.git:
     - root: salt/root
   - https://<user>:<pass>@gitlab/salt-master.git:
     - root: salt/formulas
ext_pillar:
   - git: __env__ https://<user>:<pass>@gitlab/salt-master.git root=pillar

Note that the __env__ in the ext_pillar definition is available since 201502

The top.sls for states (salt/root/top.sls) looks like:
{{env}}: # Will be the current value for saltenv (i.e. the git branch)
   '*':
     # state references

The top.sls for pillars (pillar/top.sls) looks like:
{{env}}: # Will be the current value for saltenv (i.e. the git branch)
   '*':
     # pillar references

This way, all (read: states and pillars) can be used from the same branch.
The states are combined from salt/root and salt/formulas. The latter is a
("my") copy from external formulas, that can (e.g. partially) be overridden
in salt/root. To develop changes, just create a new branch and run salt
commands with saltenv=<branch name>. In the mean time it's still safe to
run salt commands on the default saltenv=base (i.e. master branch).

To make a clear distinction on what is used for what, I've implemented a
states with minimal logic. In short: the states = how and the pillar =
what. Or in words the states are only for determining how services etc. are
configured and the pillars determine which states are used and what
parameters are used.

Therefore the states top.sls is extended and looks like:
{{env}}: # Will be the current value for saltenv (i.e. the git branch)
   '*':
     # Now the states defined in the pillar
{% for state, enabled in pillar.get('states', {}).iteritems() %}
{% if enabled %}
     - {{ state }}
{% endif %}
{% endfor %}

The corresponding pillar top.sls:
{{env}}: # Will be the current value for saltenv (i.e. the git branch)
   '*':
     - settings

Which uses the settings pillar (settings/init.sls):
include:
   - settings.{{ grains['management-domain'] }

And the 'example' management domain (settings/example.sls):
{% if grains.get('managed') in ['salt'] %} # Ignore unmanaged minions
{% if grains['os_family'] in ['Windows'] %}
{% else %} # NOT grains['os_family'] in ['Windows']

# Include pillars used in states te be determined later on
include:
   - openssh
   - ntp
   - snmp

# Track these states into pillar['states'] to be executed in salt states
# This can be repeated, but not with the same entries (conflicting keys
# will be overwritten in a non-deterministic manner!
# See: http://salt.readthedocs.org/en/latest/topics/pillar/
states:
   openssh: True
   openssh.config: True
   openssh.zxbeheer: True
   # ntp: True
   snmp: True
{% endif %} # grains['os_family'] in 'Windows'
{% else %} # NOT grains.get('managed') in ['salt']
{% endif %} # grains.get('managed') in ['salt']

Note that here the following non-standard grains are used (set manually):
managed:salt, management-domain:example

Having this is place, the following would be nice to. When you're working
on a system and have a git branch created for your work (say,
'work-branch'), you don't want someone else (or a cronjob) to interfere.
For that a dedicated grain can be created, which is here named
'salt-branch'. If you set this to 'work-branch', highstate should only work
when it is for the designated branch ('work-branch' in this case). Just set
that with 'salt <minion id> grains.setval salt-branch work-branch' (and
remove this with 'salt <minion id> grains.delval salt-branch
destructive=True').

Now the top.sls for states (salt/root/top.sls) will look like:
# Use the current value for saltenv (i.e. the git branch), unless
# the grain salt-branch is set. In the latter case, this grain
# will be used, which will fail if grains['salt-branch'] != env
{{ grains.get('salt-branch', env) }}:
   '*':
     # state references

And the top.sls from the pillar (pillar/top.sls) will be:
# Use the current value for saltenv (i.e. the git branch), unless
# the grain salt-branch is set. In the latter case, this grain
# will be used, which will fail if grains['salt-branch'] != env
{{ grains.get('salt-branch', env) }}:
   '*':
     - settings

Now, a highstate with another saltenv than work-branch will fail for those
minions that have set the grain salt-branch:work-branch. The failure will
look like:
<minion id>:
----------
           ID: states
     Function: no.None
       Result: False
      Comment: No Top file or external nodes data matches found
      Started:
     Duration:
      Changes:


Well, this is a possible implementation. It differs somewhat from what is
done elsewhere. Comments are welcome :-)


Cheers,

Kees



--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 1 | next ›
Discussion Overview
groupsalt-users @
postedApr 8, '15 at 7:38a
activeApr 8, '15 at 7:38a
posts1
users1

1 user in discussion

Kees Bos: 1 post

People

Translate

site design / logo © 2022 Grokbase