how to get the jid for a specific orchestration when triggered via salt's reactor system

[Hadi B]

I have a reactor that triggers salt orchestration.

deploy-win-active-directory:
  runner.state.orchestrate:
    - mods: orchestration.deploy_win_active_directory
    - pillar:
        tgt: {{ data['tgt'] }}

when the orchestration is started via the reactor the following would be posted to the salt's event bus

salt/run/20170228113356410801/new       {
    "_stamp": "2017-02-28T10:33:56.413398",
    "fun": "runner.state.orchestrate",
    "jid": "20170228113356410801",
    "user": "Reactor"
}

My question is: if we have multiple orchestrations running on different target minions, is there a way to relate a jid returned to the event bus with that specific minion the orchestration is running on? so by using that jid, we could look up for this tag 'salt/run/20170228113356410801/ret'  in returned data to the event bus and see if the orchestration that ran successfully or failed.

[Seth House]

IMO, it's an oversight that arg/kwarg are not present in that 'new'
event. That is the case for jobs sent down to minions so I think it
should be the case here too. Runner events are a fairly new addition.

Please file an issue in the Salt repository to get that added (I'd
appreciate a tag on it too: @whiteinge).

In the meantime, I can't think of an easy way to correlate those two.
I think you'd necessarily need to ignore the 'new' events and only
process the 'ret' events for the info you need.

> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/salt-users/c0195540-d9e3-42ee-8eef-0a6746b59597%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hadi B]

The returned dict contains unknown levels of nested dictionaries that would vary differently, since we have different orchestration state files. Therefore, it would require us to put in place one script/runner for every orchestration file to look for known nested key, values in the returned dictionary in the event bus.  I put a sample ret output below.
I will also post this issue on github and hope there could be a fix for it.

_stamp: '2017-02-28T10:34:11.979946'
fun: runner.state.orchestrate
jid: '20170228113356410801'
return:
    data:
        salt0100_master:
            salt_|-step_i_|-step_i_|-state:
                __id__: step_i
                __run_num__: 0
                changes:
                    out: highstate
                    ret:
                        win-minion02:
                            module_|-**-service_status_|-service.status_|-run:
                                __id__: **_service_status
                                __run_num__: 0
                                changes:
                                    ret: true
                                comment: Module function service.status executed
                                duration: 16.0 ms
                                name: service.status
                                result: true
                                start_time: '11:33:57.942000'
                comment: States ran successfully. Updating win-minion02.
                duration: 5118.835 ms
                name: step_i
                result: true
                start_time: '11:33:56.681965'
            salt_|-step_ii_|-step_ii_|-state:
                __id__: step_ii
                __run_num__: 1
                changes:
                    out: highstate
                    ret:
                        win-minion02:
                            module_|-**_service_status_|-service.status_|-run:
                                __id__: **_service_status
                                __run_num__: 0
                                changes:
                                    ret: true
                                comment: Module function service.status executed
                                duration: 17.0 ms
                                name: service.status
                                result: true
                                start_time: '11:34:02.941000'
                comment: States ran successfully. Updating win-minion02.
                duration: 5088.168 ms
                name: step_ii
                result: true
                start_time: '11:34:01.801405'
            salt_|-step_iii_|-step_iii_|-state:
                __id__: step_iii
                __run_num__: 2
                changes:
                    out: highstate
                    ret:
                        win-minion02:
                            module_|-**_service_status_|-service.status_|-run:
                                __id__: **_service_status
                                __run_num__: 0
                                changes:
                                    ret: true
                                comment: Module function service.status executed
                                duration: 0.0 ms
                                name: service.status
                                result: true
                                start_time: '11:34:08.129000'
                comment: States ran successfully. Updating win-minion02.
                duration: 5082.723 ms
                name: step_iii
                result: true
                start_time: '11:34:06.890252'
        retcode: 0
    outputter: highstate
success: true
user: Reactor