Orchestration runner, highstates and environment question.

202 views
Skip to first unread message

Anton

unread,
Apr 14, 2015, 4:57:37 AM4/14/15
to salt-...@googlegroups.com
Hello, i have a question about using orchestrate runner with multiple environments.

I have multiple environments and used to work with highstate on them, using declarative description in top.sls in states and in top.sls in pillar.
Them i tried to move to orchestration system as my states on minions begin to depend on each other.
When i made an orchestrate sls file and wrote highstates only there and added some requirements in order to describe my top.sls cross minions dependencies, i ran into a big problem using orchestrate runner: execution like salt-run state.orch orchestration.mycluster uses only base environment.
U can see in develop branch code like this:
def orchestrate(mods, saltenv='base', test=None, exclude=None, pillar=None):
It was a disappointment for me. I really don't understand why do u have to restrict explicit env specification when running orchestrate, while when using state.highstate environments and appropriate matches for them could be declarative described in top.sls.

Is it a bug or my misunderstanding? Please, help.

Also in new rc there is an orchestrate_highstate runner, can u tell, what is it for? I tried using it, but it failed with exception.

Anton

unread,
Apr 15, 2015, 5:51:34 AM4/15/15
to salt-...@googlegroups.com
Someone, please answer.

Anton

unread,
Apr 20, 2015, 5:39:37 AM4/20/15
to salt-...@googlegroups.com
?

On Tuesday, April 14, 2015 at 11:57:37 AM UTC+3, Anton wrote:

Colton Myers

unread,
Apr 22, 2015, 6:22:26 PM4/22/15
to salt-...@googlegroups.com
Have you actually observed the orchestrate runner only using the `base` environment? Just because that's the default argument doesn't mean it's necessarily enforcing it to the state.highstate calls it makes to the minions. If it's enforcing it all the way down, we should definitely get this fixed, there's not reason to restrict orchestrate to a single environment. You should file an issue if this is the case.

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Twitter/Github/IRC

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Anton

unread,
Apr 23, 2015, 4:30:43 AM4/23/15
to salt-...@googlegroups.com
Yes, it's actually enforcing and i think it can be considered as bug as it ruins the concept of declarative environments description in highstates.

Anton

unread,
Apr 23, 2015, 4:34:36 AM4/23/15
to salt-...@googlegroups.com
Can u also give me a clue about what new orchestrate_high runner that is in develop branch is for?

Colton Myers

unread,
Apr 28, 2015, 1:06:09 PM4/28/15
to salt-...@googlegroups.com
Could you file an issue on Github? We should definitely investigate this.

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Twitter/Github/IRC

Sokratis Galiatsis

unread,
Apr 22, 2017, 12:37:29 PM4/22/17
to Salt-users
Same issue here. Tried running a highstate via the orchestrator runner but it seems that saltenv=base is enforce.
I am also at the same case as Anton, I have minions that co-extst of multiple environemnt (e.g. base + production environment)

@basepi
Has there been any improvement/fix or should we raise an issue in Github?
Message has been deleted

Sokratis Galiatsis

unread,
Apr 26, 2017, 9:38:30 AM4/26/17
to Salt-users
Any update?

Every time salt.orchestrate is called from the reactor, salt orchestrate applies all the state under base as listed in top.sls
Using a single top.sls file under base environment which works fine if called normally (e.g: salt 'minionA' state.highstate)

Environment targeting is done via pillar data. A small sample of the top.sls file:
#############
base:
  '*':
    - state1
    - state2
prod:
  'I@env:production':
    - match: compound
    - state3
#############

Sample from my orchestrate sls file:
#############
run_minion_highstate:
  salt.state:
    - tgt: 'minionA'
    - highstate: True
    - queue: True
#############

Following the above two samples, I would expect the salt.state orchestrate function for target "minionA" to apply all states (state1, state2 and state3). "minionA" does have "role:production" set in its pillar data.
Unfortunately only state1 and state2 get applied when the salt.state orchestrate function runs.

Double checked sat-master event bus (via salt-run state.event) and it reports executing:
#############
    "fun": "runner.state.orchestrate", 
    "fun_args": [
        [
            "orchestrate.minion.highstate" 
        ], 
        {
            "exclude": null, 
            "orchestration_jid": null, 
            "pillar": {
                "event_data": {
                    "_stamp": "2017-04-26T12:54:17.880661", 
                    "cmd": "_minion_event", 
                    "data": "Minion minionA started at Wed Apr 26 12:54:17 2017", 
                    "id": "minionA", 
                    "pretag": null, 
                    "tag": "salt/minion/minionA/start"
                }, 
                "event_tag": "salt/minion/minionA/start"
            }, 
            "pillarenv": null, 
            "saltenv": "base", 
            "test": null
        }
    ], 
##############
I bet the route of this issue is the lack of the pillarenv variables but I do not see a reason for setting it. I would expect reactor->orchestrate flow to follow the same principles of operation as "salt 'minionA' state.highstate"/

Also experimented a lot with top_file_merging_strategy but without any success.

############### Master
Salt Version:
           Salt: 2016.11.4
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: 5.6.0
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.8.1
        libgit2: 0.20.0
        libnacl: Not Installed
       M2Crypto: 0.20.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: 3.4.3
         pygit2: 0.20.3
         Python: 2.6.6 (r266:84292, Aug 18 2016, 15:13:37)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.5.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.0.5
 
System Versions:
           dist: centos 6.9 Final
        machine: x86_64
        release: 2.6.32-696.el6.x86_64
         system: Linux
        version: CentOS 6.9 Final

############### Minion
Salt Version:
           Salt: 2016.11.4
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.8.1
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.20.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: 3.4.3
         pygit2: Not Installed
         Python: 2.6.6 (r266:84292, Aug 18 2016, 15:13:37)
   python-gnupg: Not Installed
         PyYAML: 3.11
          PyZMQ: 14.5.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: 0.2.4
        Tornado: 4.2.1
            ZMQ: 4.0.5
 
System Versions:
           dist: centos 6.9 Final
        machine: x86_64
        release: 2.6.32-696.1.1.el6.x86_64
         system: Linux
        version: CentOS 6.9 Final

On Tuesday, April 28, 2015 at 8:06:09 PM UTC+3, basepi wrote:
Reply all
Reply to author
Forward
0 new messages