saltenv not used from roster with salt-ssh state.apply

[vbasem]

Description of Issue/Question

I am trying to define saltenv in my roster files and have the correct environment applied when salt-ssh is called. What I observe is state.apply always seems to default to "base" environment, which pillar.items uses the correct saltenv defined in the roster.

Setup

roster

  user: root
  host: localhost
  minion_opts:
    environment: cloud_local
    saltenv: cloud_local
    pillarenv_from_saltenv: True

/etc/salt/master

pillarenv_from_saltenv: True
pillar_source_merging_strategy: none

file_roots:
  cloud_local:
    - /srv/salt/cloud/
pillar_roots:
    - /srv/pillar/cloud/local

test.sls

doit:
  cmd.run:
    - name: echo {{ saltenv }}

top.sls

{{saltenv}}
  '*':
    - test

Steps to Reproduce Issue

1. salt ssh will output base (expected is cloud_local)

salt-ssh localhost state.apply test

2. salt ssh will output cloud_local

salt-ssh localhost state.apply test saltenv=cloud_local

1. salt call will output cloud_local (put saltenv: cloud_local in minion file)

salt-call state.apply test

Versions Report

(master, minion and ssh are all the same version)

Salt Version:
           Salt: 2018.3.2

Dependency Versions:
           cffi: 1.11.5
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.28.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.19
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.5 (default, Nov  6 2016, 00:28:07)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.1.4

System Versions:
           dist: centos 7.3.1611 Core
         locale: UTF-8
        machine: x86_64
        release: 3.10.0-514.26.2.el7.x86_64
         system: Linux
        version: CentOS Linux 7.3.1611 Core

[gtmanfred]

Yup, this is a bug with saltenv, the state.sls wrappers default to base and do not look at the minion_opts for knowing if a saltenv is specified.

Thanks for reporting.
Daniel

[Arendtsen]

Would this bug also affect salt-call?
I have the exact same situation.

[mbochenk]

Same issue with salt-ssh.

• if I set up saltenv in roster, it does not work
• if pillarenv_from_saltenv: True seems to apply to pillarenv (saltenv remains base)
• if I add saltenv=some_env to invocation - works

Salt Version:
           Salt: 2018.3.3
 
Dependency Versions:
           cffi: 1.11.5
       cherrypy: Not Installed
       dateutil: 2.7.5
      docker-py: Not Installed
          gitdb: 0.6.4
      gitpython: 1.0.1
          ioflo: 1.3.8
         Jinja2: 2.7.2
        libgit2: 0.26.3
        libnacl: 1.6.1
       M2Crypto: 0.28.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.18
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: 0.26.4
         Python: 2.7.5 (default, Oct 30 2018, 23:45:53)
   python-gnupg: 0.4.3
         PyYAML: 3.13
          PyZMQ: 15.3.0
           RAET: Not Installed
          smmap: 0.9.0
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.1.4
 
System Versions:
           dist: centos 7.6.1810 Core
         locale: UTF-8
        machine: x86_64
        release: 4.4.163-1.el7.elrepo.x86_64
         system: Linux
        version: CentOS Linux 7.6.1810 Core

[gtmanfred]

@saltstack/team-triage can you take a look at this?