Reputation: 467
I'm using SaltStack to manage some VMs. I'm looking for a way to render the ID/hostname of a minion(s) that have a specified .sls attached to them in the top.sls file or a particular state in a jinja template-enabled file. The reason I want to do this is so I can easily refer to a server(s) in a client's configuration without having to hardcode values anywhere at all. For example;
/srv/salt/top.sls:
base:
'desktoppc01':
- generic.dns
'bind9server01':
- generic.dns
- bind9
/srv/salt/generic/dns/init.sls:
/etc/resolv.conf:
file:
- managed
- source: salt://generic/dns/files/resolv.conf
- mode: 644
- template: jinja
And finally,
/srv/salt/generic/dns/files/resolv.conf:
domain {{ pillar['domain_name'] }}
search {{ pillar['domain_name'] }}
nameserver {{ list_minions_with_state['bind9'] }}
What I'm after specifically is an equivalent to {{ list_minions_with_state['bind9'] }}
(which I just made up for demonstrations sake). I had assumed it would be something that would be pretty commonly needed, but after scouring the modules page I haven't found anything yet.
At the moment I have the client get information from a pillar, but this has to be manually configured which doesn't feel like time well spent.
I'm hoping I could expand this idea with a for
loop so that servers are dynamically added as they're created.
edit:
With a file with the same data & hierarchy as a top.sls, rendering
base:
{% for server_id in salt['pillar.get']('servers') %}
'{{ server_id }}':
{% for states in salt['pillar.get']('servers:{{ server_id }}') %}
- {{ states }}
{% endfor %}
{% endfor %}
gives you
base:
'desktoppc01':
'bind9server01':
I tried a few variations on {{ server_id }}
but was unsuccessful. Unless there's an easy way to use pillar variables in that function, I'm thinking of making a feature request and calling it a day.
Upvotes: 0
Views: 3643
Reputation: 130
The first thing that comes to mind would be using the test-state methodology by setting test=True for state.apply or state.highstate. If there were zero states to apply then your server would have your highstate or specific sls fully applied.
salt '*' state.highstate test=True
Using salt-run's survey.diff could be helpful (although the diff patch doesn't lend itself well to this scenario as much as examining config files):
salt-run survey.diff '*' state.apply my.state test=True
While not currently applicable to your question based on your examples another method that comes to mind would be to use salt grains within your states. When you have your states applied to the systems the state would append to the "states" grain. Grains track things like roles (eg. web, database, etc.) in your case grains could track states as more of a what was applied, instead of a what should be logic of roles. Then you can use them to target and/or query your servers.
Targeting by Grain (show only minion id's) :
salt -G 'states:bind9' test.ping
salt -G 'states:generic.dns' test.ping
salt -G 'states:my_jinja_state' test.ping
Querying Grains (for each minion show me the states grain):
salt '*' grains.get states
Diffing of Grains (compare each minions states grain):
salt-run survey.diff '*' grains.get states
Upvotes: 0
Reputation: 244
The way I think around this problem is to use jinja and have a variable that contain the list of dns server... populated by a pillar variable
for instance you could have a pillar:bind:servers variable see http://docs.saltstack.com/en/latest/topics/tutorials/states_pt3.html and http://docs.saltstack.com/en/latest/topics/pillar/index.html#master-config-in-pillar
that can be used to both setup the nameserver of resolv.conf.. but also to add the - bind9 state to the servers. so in the end you have just one place to edit: the list of minion that are bind server in pillar
Upvotes: 1