<p>SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. </p>

<p>For example:
1. add grains to the minion config. Note, simply include the grains key here:</p>

<blockquote>
<pre><code>id: minion-07
grains:
  roles:
    - production
  region: nl-amsterdam
</code></pre>
</blockquote>

<ol start="2">
<li>add custom grains within the /etc/salt/grains file. Note, add grains without prefacing them with grains:</li>
</ol>

<blockquote>
<pre><code>   roles:
       - production
     region: nl-amsterdam
</code></pre>
</blockquote>

<ol start="3">
<li>Alternatively you may set roles via command line shell from master or from salt minion: </li>
</ol>

<blockquote>
  <p><code>salt 'your minion' grains.setval roles [production, dev, qa]</code></p>
  
  <p><code>salt-call grains.setval roles [production, dev, qa]</code></p>
</blockquote>

<p>For matching grains I usually use Jinja2. Or you may refer to commandline/config file approaches: </p>

<blockquote>
  <p><code>salt -C 'G@roles:production' test.ping</code></p>
</blockquote>

<p>By using sytnax in the top.sls file:</p>

<blockquote>
<pre><code>base:
  'roles:production':
    - match: grain
    - salt.master
  'roles:dev':
    - match: grain
    - api-dev
</code></pre>
</blockquote>

<p>Alternatively you may consider using environments in SaltStack, see here for more details: <a href="https://docs.saltstack.com/en/latest/ref/states/top.html#environments" rel="nofollow noreferrer">https://docs.saltstack.com/en/latest/ref/states/top.html#environments</a></p>

<p>However, roles are more suitable for running specific states, at least We use them in our our company. So up to you what is the best ;) </p>

CC BY-SA 3.0
2017-08-14T09:22:24.293Z
Thank you for the answer @user54 - This is exactly what I was looking for, we used this method at my old workplace, except it was already implemented before my arrival so I've never had any experience configuring it myself!
jto
CC BY-SA 3.0
2017-08-15T14:33:18.280Z
Always glad to help 
user54
CC BY-SA 3.0
2017-08-12T22:40:49.677Z
2017-08-12T23:02:37.800Z
2017-08-12T23:02:37.800Z
user54
<p>I have been tasked with using Salt Stack to find out what files/services exist in each of our environments (Test, UAT, Production).</p>

<p>The Salt master can speak to all servers in Test and UAT (Production Salt master is yet to be configured) so I was thinking of creating a state in 'base' which can target all minions just doing simple file.exist queries. However I quickly came to the realisation that certain files won't exist on certain servers due to the different nature of them. E.g. Our API server has a lot of specific scripts and configs which won't exist on our LDAP server.</p>

<p>What is the most efficient and scalable way of implementing this? Could I define roles for each type of server (e.g. webserver, ldap server, api server) and therefore a specific state for each role?</p>

<linux><configuration-management><salt><scalability>
Best method of retrieving environment information via Salt Stack?
jto
# Best method of retrieving environment information via Salt Stack?

(Asked by: username_0 on 2017-08-11)

I have been tasked with using Salt Stack to find out what files/services exist in each of our environments (Test, UAT, Production).

The Salt master can speak to all servers in Test and UAT (Production Salt master is yet to be configured) so I was thinking of creating a state in 'base' which can target all minions just doing simple file.exist queries. However I quickly came to the realisation that certain files won't exist on certain servers due to the different nature of them. E.g. Our API server has a lot of specific scripts and configs which won't exist on our LDAP server.

What is the most efficient and scalable way of implementing this? Could I define roles for each type of server (e.g. webserver, ldap server, api server) and therefore a specific state for each role?

**Tags:** linux, configuration-management, salt, scalability


---

## 1 answers

### Answer by username_1 on 2017-08-12. Score: 3 | Accepted answer

SaltStack provides a method for modifying grains and adding additional information to the grains dictionary in several different ways by either setting them in the /etc/salt/minion config and/or through the /etc/salt/grains file. 
For example:
1. add grains to the minion config. Note, simply include the grains key here:

id: minion-07
grains:
  roles:
    - production
  region: nl-amsterdam



add custom grains within the /etc/salt/grains file. Note, add grains without prefacing them with grains:


   roles:
       - production
     region: nl-amsterdam



Alternatively you may set roles via command line shell from master or from salt minion: 


salt 'your minion' grains.setval roles [production, dev, qa]
salt-call grains.setval roles [production, dev, qa]

For matching grains I usually use Jinja2. Or you may refer to commandline/config file approaches: 

salt -C 'G@roles:production' test.ping

By using sytnax in the top.sls file:

base:
  'roles:production':
    - match: grain
    - salt.master
  'roles:dev':
    - match: grain
    - api-dev


Alternatively you may consider using environments in SaltStack, see here for more details: https://docs.saltstack.com/en/latest/ref/states/top.html#environments
However, roles are more suitable for running specific states, at least We use them in our our company. So up to you what is the best ;)

> **Comments:**
> **username_0**: Thank you for the answer @username_1 - This is exactly what I was looking for, we used this method at my old workplace, except it was already implemented before my arrival so I've never had any experience configuring it myself!  
> **username_1**: Always glad to help   

---

