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.

1 Answer 1

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
2
  • I must have missed the notification on this one. I'll try this out today or early next week. Thanks a lot.
    – Mike
    Feb 2, 2018 at 10:06
  • I'm getting error 'no matching salt environments' for such setup
    – wl2776
    Mar 1, 2019 at 9:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .