0

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.

user2640621
  • 437
  • 5
  • 7
  • You could use Salt Mine to achieve something close to this...e.g. set up a mine function returning a minion's hostname (or ip address, or whatever), and then do a mine.get for the IPs of all servers matching a particular pattern -- presumably the same pattern you're using to assign the relevant state in top. – Andrew Jul 25 '18 at 22:00

2 Answers2

1

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

nthiebaud
  • 214
  • 2
  • 6
  • That seems like it would enable what I'm trying to achieve (at the cost of being pretty hacky and moving the important information to a pillar), but I can't variables to work within the `pillar.get` function, as per the edit in the OP. – user2640621 Apr 23 '14 at 11:04
  • {% for states in salt['pillar.get']('servers:{{ server_id }}') %} – nthiebaud Apr 24 '14 at 15:58
0

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
Illuminatus
  • 31
  • 2