Way in Salt to use a different configuration file for a single command

saltstack

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 ?

Best Answer

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.

Related Solutions

How to use saltstack to manage different config file for different minions

Just add - template: jinja to your file.managed and you can use grains in configuration files.

/etc/httpd/conf.d/httpd-vhosts.conf:
  file.managed:
    - source: salt://webserver/httpd-vhosts.conf
    - template: jinja

You can use grains in the sourced file like so:

{% if grains['id'] == 'dev' -%}
ServerName dev.example.com
{% else %}
ServerName example.com
{% endif -%}

It is this very feature that sold me on SaltStack.

Salt State Testing via Jenkins

Docker. Quick automated testing of server configuration is an undeniable real-world problem that docker nails. It can provide a clean computer already booted and listening on the network in a second. Start an image with /srv/salt bind-mounted and you can run salt-call --local state.highstate -l debug to test states without fussing with salt-key.

I know SaltStack, Inc used LXC much the same way. They likely still do.

As for the test - if you are clever and careful with your states files you could consider a clean second run to be an indication of success.

This is difficult to achieve as some states will always re-run. Salt Stack has been good at fixing these states as they are found. In the meantime you will have to surround these states with inline jinja conditionals that execute commands on the minion at runtime:

{% if salt['cmd.retcode']('your test here') %} 
some-identifier:
  some.module:
    - name: some anme
{% endif %}'

There exists a jenkins-docker plugin:

The aim of the docker plugin is to be able to use a docker host to dynamically provision a slave, run a single build, then tear-down that slave.

Alternatively, you can automate the whole thing via the new docker-ng salt module:

salt dockhost docker-ng.create states-qa rm=True binds="/srv/salt:/srv/salt"
salt dockhost docker-ng.retcode states-qa 'salt-call --local state.highstate' # run 1
salt dockhost docker-ng.retcode states-qa 'salt-call --local state.highstate' # run 2
salt dockhost docker-ng.stop states-qa

Best Answer

Related Solutions

How to use saltstack to manage different config file for different minions

Salt State Testing via Jenkins

Related Topic