state.highstate states order problem.

[0megam]

Description of Issue/Question

I have a problem with state.highstate states order execution.

Setup

Here is my /etc/salt/master settings:

file_roots:
    base:
      - /srv/salt/base
    dev:
      - /srv/salt/dev
    prod:
      - /srv/salt/prod
    qa:
      - /srv/salt/qa

env_order: ['base', 'qa', 'dev', 'prod']

/srv/salt/base/top.sls

base:
  '*':
    - environment
    - ntp
    - resolver
    - netdata
    - dis_hugepages
    - htop
    - redis-server
    - vim
dev:
  'role:developers':
    - match: grain
    - join-domain
    - libpam-mount
    - sshd-config
    - google-chrome
    - webstorm
    - mate-desktop
    - xrdp
    - add-shortcuts
    - monodevelop
    - limits
qa:
  'role:mongodb':
    - match: grain
    - mongodb
  'role:meteor':
    - match: grain
    - node
    - meteor_deploy
  'role:java':
    - match: grain
    - sun-java
    - japp
  'role:developers':
    - match: grain
    - node
    - mongodb

Steps to Reproduce Issue

Then i execute salt '*xxx25' state.highstate --state-output=terse i got this output:

xx-xxx-xxx25:
  Name: apt-transport-https - Function: pkg.installed - Result: Clean
  Name: deb http://deb.nodesource.com/node_5.x trusty main - Function: pkgrepo.managed - Result: Clean
  Name: nodejs - Function: pkg.installed - Result: Clean
  Name: deb http://deb.xxp.xxx/repo.mongodb.com/apt/ubuntu trusty/mongodb-enterprise/stable multiverse - Function: pkgrepo.managed - Result: Clean
  Name: mongodb-enterprise - Function: pkg.installed - Result: Clean
  Name: /mongodb/data - Function: file.directory - Result: Clean
  Name: /mongodb/log - Function: file.directory - Result: Clean
  Name: /etc/mongod.conf - Function: file.managed - Result: Clean
  Name: mongod - Function: service.running - Result: Clean
  Name: python-pip - Function: pkg.installed - Result: Clean
  Name: pymongo - Function: pip.installed - Result: Clean
  Name: meteor - Function: mongodb_user.present - Result: Clean
  Name: /etc/environment - Function: file.managed - Result: Clean
  Name: ntp - Function: pkg.installed - Result: Clean
  Name: /etc/ntp.conf - Function: file.managed - Result: Clean
  Name: ntp - Function: service.running - Result: Clean
  Name: /etc/resolv.conf - Function: file.managed - Result: Clean
  Name: build_env - Function: pkg.installed - Result: Clean
  Name: /tmp/ - Function: archive.extracted - Result: Clean
  Name: cd /tmp/netdata-master/
./netdata-installer.sh
 - Function: cmd.run - Result: Clean
  Name: /etc/init.d/disable-transparent-hugepages - Function: file.managed - Result: Clean
  Name: disable-transparent-hugepages - Function: service.running - Result: Clean
  Name: service disable-transparent-hugepages start - Function: cmd.run - Result: Clean
  Name: htop - Function: pkg.installed - Result: Clean
  Name: redis-server - Function: pkg.installed - Result: Clean
  Name: vim - Function: pkg.installed - Result: Clean
  Name: /var/tmp/pbis-open-8.3.0.3287.linux.x86_64.deb.sh - Function: file.managed - Result: Clean
---cut---
Summary for xx-xxx-xxx25
-------------
Succeeded: 68
Failed:     0
-------------
Total states run:     68

From output i assume that states executed in wrong order.I expect execution in this order: base qa then dev environments, but for some unknown reason (for me ;) ) states are executed in this order: qa base dev. Here is output of salt '*xxx25' state.show_lowstate --out yaml | grep env :

- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: qa
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: base
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev
- __env__: dev

That i am doing wrong ?

Versions Report

Salt Version:
           Salt: 2015.8.8.2

Dependency Versions:
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
           Mako: 0.9.1
         PyYAML: 3.10
          PyZMQ: 14.0.1
         Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.4
           cffi: Not Installed
       cherrypy: 3.2.2
       dateutil: 1.5
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: Not Installed
        libgit2: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.3.0
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: 0.8.2
        timelib: Not Installed

System Versions:
           dist: Ubuntu 14.04 trusty
        machine: x86_64
        release: 3.19.0-43-generic
         system: Ubuntu 14.04 trusty

[cachedout]

You likely need to alter the top_file_merging_strategy configuration option.

[0megam]

If i set top_file_merging_strategy to same only base environment states are applied. States from dev and qa environments are not applied even if i specifying saltevn argument.

[cachedout]

Try setting ordered_top_files: True in your minion config and see if that helps, please.

[0megam]

@cachedout Sorry for really late answer. Your suggestion does not help. I see same behavior.

[0megam]

@cachedout Same behavior on 2016.3.4.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.