2

The documentation states that if you use

salt_top_saltenv: base

in the master config, that I can force all Minions to only use the base saltenv for the top file, ignoring all other top files, is that correct?

With state_top_saltenv set to base, all states from all environments in the base top file will be applied, while all other top files are ignored

I am trying to use Gitfs as the back end and am getting some strange results (state.show_top) is not matching anything.

I have the following configuration

  • A single git repository
  • 4x refs, base,development,staging,production

I am trying to achieve a single refs (base) for the top file and then the states from each environment. Then I can promote changes through the environments via merging, and try and keep the top.sls as static as possible.

##### Salt Master config #####

salt_top_saltenv: base
top_file_merging_strategy: same
gitfs_base: base

gitfs_saltenv:
  - base:
    - ref: base
  - development:
    - ref: development
  - staging:
    - ref: staging
  - production:
    - ref: production
gitfs_remotes:

  # Salt States
  - ssh://git@mydomain.com/Salt.git:
    - name: salt
    - root: states
    - mountpoint: salt://


##### How the repo is laid out #####

# Base Branch

README.md
.gitignore
states/top.sls

# Development Branch

README.md
.gitignore
states/Test/init.sls

# Staging Branch

README.md
.gitignore
states/Test/init.sls

# Production Branch

README.md
.gitignore
states/Test/init.sls


##### Top.sls #####

{# The saltenv variable represents the environment the Minion is configured 
to #}
{{ saltenv }}:

  '*':

    # Apply states.test to everything from the matching env
    {%- do salt.log.info("Applying Salt states.test from" + saltenv + 
"environment" ) %}
- states.Test


##### Example Minion config ######

master: salt-master.mydomain.com
saltenv: development


From the Minion I am able to list the files on the Master correctly as 
expected

# Not specifying the saltenv results in the base being used
sudo salt '*' cp.list_master

top.sls

# Specifying the Base saltenv
sudo salt '*' cp.list_master saltenv=base

top.sls

# Specifying the Development saltenv
sudo salt '*' cp.list_master saltenv=development

Test/init.sls

When I attempt to show the top match Salt is looking in the development environment instead of Base like I am expecting

sudo salt-call state.show_top --log-level=debug

[DEBUG   ] Could not find file 'salt://top.sls' in saltenv 'development'
[DEBUG   ] No contents found in top file. If this is not expected, verify that the 'file_roots' specified in 'etc/mas
ter' are accessible. The 'file_roots' configuration is: {'production': [], 'development': [], 'staging': [], 'base':
[]}
[ERROR   ] The 'development' saltenv has no top file, and the fallback saltenv specified by default_top (base) also h
as no top file

[DEBUG   ] Could not find file 'salt://top.sls' in saltenv 'development'
[DEBUG   ] No contents found in top file. If this is not expected, verify that the 'file_roots' specified in 'etc/mas
ter' are accessible. The 'file_roots' configuration is: {'production': [], 'development': [], 'staging': [], 'base':
[]}
[ERROR   ] The 'development' saltenv has no top file, and the fallback saltenv specified by default_top (base) also h
as no top file

[DEBUG   ] Could not find file 'salt://top.sls' in saltenv 'development'
[DEBUG   ] No contents found in top file. If this is not expected, verify that the 'file_roots' specified in 'etc/mas
ter' are accessible. The 'file_roots' configuration is: {'production': [], 'development': [], 'staging': [], 'base':
[]}
[ERROR   ] The 'development' saltenv has no top file, and the fallback saltenv specified by default_top (base) also has no top file

So whats the best way to achieve a single top.sls in Base, and all other states in saltenv's?

Cheers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.