| | 43 | This is a slightly more complex set up with multiple environments. The roots for each environment are set in /etc/salt/master, under file_roots and pillar_roots. |
| | 44 | |
| | 45 | When referring to a state or pillar, salt looks for the matching id in the corresponding environment tree, here base, orbit, or winlab. However, TOP FILES ARE GLOBAL. There is nothing stopping you from targeting an orbit machine with a winlab state, or both via sloppy use of wildcards. |
| | 46 | |
| | 47 | This can be used to benefit by putting common configuration under the base tree, and only keeping environment specific states under their respective trees. Code reuse means we fix problems fewer times. Environment specific configuration will in most cases be in pillars, not states anyway. |
| | 48 | |
| | 49 | It is possible to have multiple top files, but salt merges them upon execution, so it is better to manually configure it. |
| | 50 | |
| | 51 | === Usage === |
| | 52 | The simplest use case is remote execution, with the format: |
| | 53 | {{{ salt 'client pattern match' cmd.run 'command' }}} |
| | 54 | This will match all clients in the pattern match, and execute that command, returning the result. |
| | 55 | |
| | 56 | To apply a specifc state: |
| | 57 | {{{ salt 'client pattern match' state.apply environment:state_id }}} |
| | 58 | |
| | 59 | To apply the configuration from the top file: |
| | 60 | {{{ salt 'client pattern match' state.apply}}} |
