saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
https://repo.saltproject.io/
Apache License 2.0
14k stars 5.47k forks source link

[FEATURE REQUEST] Use minion saltenv as the default environment for "source" in modules #58362

Open Sxderp opened 3 years ago

Sxderp commented 3 years ago

Is your feature request related to a problem? Please describe. As an example, if running a cmd.script from the command line (salt-call cmd.script ...) the salt environment of the source file must be specified if it is not located in base. This is problematic and can be somewhat confusing when you have saltenv: set in the minion config. It's even more confusing when lock_saltenv: is set as it makes a command that should be invalid, valid:

ex (This is valid even when lock_saltenv is set) salt-call cmd.script salt://scriptfile saltenv=dev

Describe the solution you'd like

Use the configured environment as the default.


This is probably a pretty big change as "source" is used in a number of locations, but it's pretty annoying.

max-arnold commented 3 years ago

I also noticed this a while ago. Actually, it is not even clear what this minion saltenv setting affects... The docs have this vague phrase Remember that the recommended way to manage environments is to isolate via the top file and do not have any details on what is different.

In my use case, I wanted to ship different custom modules for different saltenvs, but functions like saltutil.sync_modules use base saltenv even if a minion has a different environment defined. The only way that worked for me is to assign minion environments via the top file.

Sxderp commented 3 years ago

I digress from the OP to answer this. I think it's orthogonal to the original request.


In my use case, I wanted to ship different custom modules for different saltenvs

The way we do this is assign a separate "root" for every environment in the master configuration. We also do not use "base". That is, it has a defined entry but the file root is empty. Example master config:

file_roots:
  base:
    - /srv/salt/base # This is empty
  staging:
    - /srv/salt/staging
  workstations:
    - /srv/salt/workstations

Since each environment has a separate file root we don't have to worry about multiple environments inside a single top file [1]. At the top our top.sls we key off of {{ saltenv }}: which just means "use whatever environment the minion provides as a match". Since the file roots are separate there's no worry about cross-contamination.

One problem with this is that you have duplicated data. If you want a module in both workstations and staging you need to copy them. This can be solved with clever use of Git and symlinks / hardlinks if you're so inclined.

Sxderp commented 2 years ago

It's been a while. Pinging..