Workflow execute cmd with trigger payload

(LuisN) #1

Am i doing this correctly?

action: core.local_sudo cmd="/home/test1/utils/it/info_connect_lag.sh" {{trigger.data.lag.name}} {{trigger.data.lag.url}} {{trigger.data.connected_endpoint.device.name}} {{trigger.data.connected_endpoint.name}} {{trigger.data.connected_enpoint.device.id}} {{trigger.data.name}}

Or do i create inputs and assign them the output of the trigger payload

What i have working so far is 1 rule to run script w/ trigger params above and use the payload from webhook to output results to a file.

  1. Works:
    Webhook ->st2 rule -> exec cmd sudo +trigger params -> file
  2. Does not work when the task is passed the trigger params
(Lindsay Hill) #2
action: core.local_sudo cmd="/home/test1/utils/it/info_connect_lag.sh" {{trigger.data.lag.name}} {{trigger.data.lag.url}} {{trigger.data.connected_endpoint.device.name}} {{trigger.data.connected_endpoint.name}} {{trigger.data.connected_enpoint.device.id}} {{trigger.data.name}}

That does not look right. The second " seems to be misplaced. If you want to run that script with all of those parameters as arguments, you would run it as core.local_sudo cmd="/myscript {{param1}} {{param2}}..."

Because you closed the " too soon, it’s not passing those parameters to that script.

My advice is to just focus on getting your action running manually first, then add in web hooks & rules.

What would it look like if you ran your command via CLI? st2 run <command> <params>...

(LuisN) #3

Correct I started from the ground up.
The script ran perfect without the workflow and just a rule created via gui.

Here is my latest

version: '2.0'

netbox.mistral-interface-connect:
    description: A basic workflow that runs two Linux commands (one in each task).
    type: direct
    output:
      stdout: <% $.stdout %>
    input:
    - channel
    tasks:
        task1:
            action: core.local_sudo cmd= "/home/test1/utils/it/info_connect_lag.sh {{ trigger.data.lag.name }} {{ trigger.data.lag.url }} {{ trigger.data.connected_endpoint.device.name }} {{ trigger.data.connected_endpoint.name }} {{ trigger.data.connected_enpoint.device.id }} {{ trigger.data.name }}"
            publish:
                stdout: <% task(task1).result.stdout %>
                stderr: <% task(task1).result.stderr %>
            on-success: post_success_to_slack

        post_success_to_slack:
            action: chatops.post_message
            input:
               channel: <% $.channel %>
               message: <% $.stdout %>
            on-error: post_error_to_slack
        post_error_to_slack:
            action: chatops.post_message
            input:
               channel: <% $.channel %>
               message: Error, please check snipeit logs  <% $.stdout %>
(Lindsay Hill) #4

Ah, I didn’t realize you were writing a workflow.

Those parameters like {{ trigger.data.lag.name }} make sense in the context of your rule, but it’s not in the context of your workflow.

Ignore the rule part for now. You got the action working, which is great. Now focus on running your workflow manually.

Your workflow metadata will need to specify those parameters you want to pass in, and you then refer to those parameters in that workflow context within your workflow.

Also: Do you absolutely have to run your action with core.local? In your case, I would probably do something like this Actions — StackStorm 2.10.4 documentation

(LuisN) #5

I dont have to run it with core.local. I will switch to action(s) instead.
ill report back and again, thank u!

(LuisN) #6

So I came up with the following and trying to run it via cli and not the trigger

---
description: Action that executes info_connect_lag.sh on the local host.
runner_type: "local-shell-script"
enabled: true
entry_point: 'scripts/info_connect_lag.sh'
name:juniper-interface-connect
parameters:
  sudo:
    immutable: true
  lag_name:
    type: string
    #default: {{trigger.data.lag.name}}
    position: 1
  lag_url:
    type: string
    #default: {{trigger.data.lag.url}}
    position: 2
  switch_name:
    type: string
    #default: {{trigger.data.connected_endpoint.device.name}}
    position: 3
  switch_port:
    type: string
    #default: {{trigger.data.connected_endpoint.name}}
    position: 4
  switch_id:
    type: string
    #default: {{trigger.data.connected_enpoint.device.id}}
    position: 5
  device_name:
    type: string
    #default: {{trigger.data.device.name}}
    position: 6
  device_interface:
    type: string
    #default: {{trigger.data.name}}
    position: 7
  cmd:
    default: '"{{trigger.data.lag.name}}" "{{trigger.data.lag.url}}" "{{trigger.data.connected_endpoint.device.name}}" "{{trigger.data.connected_endpoint.name}}" "{{trigger.data.connected_enpoint.device.id}}" "{{trigger.data.device.name}}" "{{trigger.data.name}}"'

If i run the script manually my output is like so , i even tested just outputting 1 variable via output and still got errors.

running script w/out st2

{
  "server": {
    "name": "test1",
    "interface": "eth0"
  },
  "switch": {
    "name": "switch1",
    "ip": "10.1.8.5",
    "interface": {
      "port": "ge-0/0/0",
      "type": {
        "ae": "ae1",
        "irb": "irb.123",
        "vlan_name": ""
      }
    }
  }
}

Error running it via cli
st2 run default.juniper-interface-connect bond0 87 switch1 ge-0/0/0 22 test1 eth0

..
id: 5ca227f755fdfa071bc8d7c3
status: failed
parameters:
  cmd: bond0 87 switch1 ge-0/0/0 22 test1 eth0
result:
  failed: true
  return_code: 1
  stderr: 'parse error: Invalid numeric literal at line 1, column 10
    curl: (23) Failed writing body (455 != 16384)
    parse error: Invalid numeric literal at line 1, column 10
    curl: (23) Failed writing body (2645 != 16384)
    parse error: Invalid numeric literal at line 1, column 10
    curl: (23) Failed writing body (2647 != 16384)
    parse error: Invalid numeric literal at line 1, column 10
    curl: (23) Failed writing body (441 != 16384)
    parse error: Invalid numeric literal at line 1, column 10
    curl: (23) Failed writing body (7030 != 16384)'
  stdout: ''
  succeeded: false

What I dont get is why does it not show the command itself being run? I tried to debug it, not much info there on output. same error msg above

Also you can see above I was trying to match the trigger output to be the default value but that did not work.

(LuisN) #7

I did some more digging on simple echo scripts

st2 run default.juniper-interface-connect lag_name=bond0 lag_url=87 switch_name=switch1 switch_port=ge-0/0/0 switch_id=22 device_name=test1 device_interface=eth0

running that

and get the result

---
description: Action that executes info_connect_lag.sh on the local host.
runner_type: local-shell-script
enabled: true
entry_point: 'scripts/info_connect_lag_netbox.sh'
name: juniper-interface-connect
parameters:
  sudo:
    immutable: true
  lag_name:
    type: string
    #default: {{trigger.data.lag.name}}
    position: 1
  lag_url:
    type: string
    #default: {{trigger.data.lag.url}}
    position: 2
  switch_name:
    type: string
    #default: {{trigger.data.connected_endpoint.device.name}}
    position: 3
  switch_port:
    type: string
    #default: {{trigger.data.connected_endpoint.name}}
    position: 4
  switch_id:
    type: string
    #default: {{trigger.data.connected_enpoint.device.id}}
    position: 5
  device_name:
    type: string
    #default: {{trigger.data.device.name}}
    position: 6
  device_interface:
    type: string
    #default: {{trigger.data.name}}
    position: 7

result:

id: 5ca2318055fdfa071bc8d7e9
status: succeeded
parameters:
  device_interface: eth0
  device_name: test1
  lag_name: bond0
  lag_url: 87
  switch_id: '22'
  switch_name: switch1
  switch_port: ge-0/0/0
result:
  failed: false
  return_code: 0
  stderr: ''
  stdout:
    server:
      interface: eth0
      name: test1
    switch:
      interface:
        port: ge-0/0/0
        type:
          ae: ae1
          irb: irb.123
          vlan_name: ''
      ip: 10.1.8.5
      name: switch1
  succeeded: true

Next step thou, how do i associate the trigger output variables to match the parameters?

(Lindsay Hill) #8

You can’t use {[trigger}} like that in your action definition. It is only relevant in your rule.

You would have action metadata like this:

---
description: Action that executes info_connect_lag.sh on the local host.
runner_type: local-shell-script
enabled: true
entry_point: 'scripts/info_connect_lag_netbox.sh'
name: juniper-interface-connect
parameters:
  sudo:
    immutable: true
  lag_name:
    type: string 
    position: 0
  lag_url:
    type: string
    position: 1
  switch_name:
    type: string
    required: true
    position: 2
  switch_port:
    type: string
    required: true
    position: 3

You would manually run it with st2 run default.juniper-interface-connect lag_name=bond0 lag_url=87 switch_name=switch1 switch_port='ge-0/0/0' switch_id=22 device_name=test1 device_interface=eth0

Your rule would be something like:

---
    name: "rule_name"                      # required
    pack: "examples"                       # optional
    description: "Rule description."       # optional
    enabled: true                          # required

    trigger:                               # required
        type: "trigger_type_ref"

    criteria:                              # optional
        trigger.payload_parameter_name1:
            type: "regex"
            pattern : "^value$"
        trigger.payload_parameter_name2:
            type: "iequals"
            pattern : "watchevent"

    action:                                # required
        ref: "default.juniper-interface-connect"
        parameters:                        # optional
            lag_name: "{{trigger.data.lag.name}}"
            lag_url: "{{ trigger.data.lag.url }}"

Have not got all parameters there, but that’s the general gist of it.

(LuisN) #9

yes, during your post and my previous I was able to get it all working under a rule. Now the next step is adding a workflow. Thank you @lhill