0

I'm working in an environment where changes in salt states and pillar must be reviewed through merge request.

At the moment, when we need to test our changes before submitting them, we log on the salt master, checkout the branch we're working on after altering our colleagues and perform our tests.

The problem with this approach is that it requires a single user to basically lock down the salt master for as long as he needs to perform test.

Hence my question : is there a way to specify a salt master configuration and/or a state/pillar root for a single salt command ?

iodbh
  • 214
  • 1
  • 10

2 Answers2

2

If you use gitfs all branches are environments in salt. So you could do something like

salt-call state.highstate saltenv=testingBranch pillarenv=testingBranch test=True

You mix and match those so if you are just testing pillar changes you can leave off the saltenv.

Mike
  • 21,910
  • 7
  • 55
  • 79
0

There is an option that allows specifying a salt master configuration file for a single command, but the content of this configuration file can't override the pillar/states roots.

After doing some research: there is a --config-dir option in salt BUT it won't override the pillar and states roots due to the asynchronous architecture of Salt (discussed on this Salt issue):

That would be useful -- however, it's hard because of the salt architecture. Basically, the salt-cli fires off a command to the minions. The minions then run that command, reaching out to the master for any files they need. The master does not match requests from minions with running CLI jobs, and so has no ability to change the file_roots or similar on the fly in that manner. They have to be changed at master runtime.

The proper way to solve this problem is to use gitfs and Salt environments, as explained in Mike's answer.

Community
  • 1
iodbh
  • 214
  • 1
  • 10