Best method of retrieving environment information via Salt Stack? 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?
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 ;)