1

Background

I have a Salt instance configured with a gitfs backend. By default, this specifies the master branch to be the base environment. So, when I execute:

salt <minion-id> state.apply

the top.sls file is executed by default.

Situation

I'd like to know if there is a way to specify/execute this top.sls file while also specifying a saltenv (to select a branch):

salt <minion-id> state.apply saltenv=<branch>

Currently, this returns:

minion-id:
-----------
ID: states
Function: no.None
Result: False
Comment: No Top file or external nodes data matches found.
Changes:

I know that I can define multiple environments in the top.sls file, but the value being passed into saltenv is somewhat dynamic. It will always contain a value of feature/, but that's the only constant part. I tried adding a wildcarded environment to the top.sls file, but that caused compilation errors. I know I can have a two-step process where feature branches get merged to a development branch which is in turn merged to master, but I'd love to avoid creating a development branch just to solve this problem.

Mike
  • 250
  • 2
  • 10

1 Answers1

2

You can accomplish a dynamic link between environments/branches available to Salt's GitFS and the top file using Jinja.

In your top.sls file, you can have a top level entry:

{{ saltenv }}:
  '*':
    - foo.bar
   ...

{{ saltenv }} will be replaced with whatever the current environment context is. Usually I define this at runtime, via:

some-minion $ sudo salt-call saltutil.sync_modules saltenv=blah
some-minion $ sudo salt-call state.apply saltenv=blah
spacez320
  • 21
  • 3