Make trace info available from within an orquesta workflow definition

SUMMARY

Make trace information for executions (or at least the current execution id) available from within orquesta workflows.

ISSUE TYPE

Pick one below and delete the rest:

• Feature Idea

Submitted per the request of @m4dcoder here: https://forum.stackstorm.com/t/is-there-a-way-to-access-the-trace-tag-of-the-rule-execution-from-the-rule-execution-itself/582

STACKSTORM VERSION

Paste the output of st2 --version:

[root@1982-sstorm-t02 ~]# st2 --version
st2 2.10.2, on Python 2.7.5

OS / ENVIRONMENT / INSTALL METHOD

Stackstorm (in its entirety) is installed on two separate VMs in a high-availability, active-active set up. There's two of everything.

Use Case

I have created a workflow that is responsible for tracking failures of a
particular stackstorm task. If that task fails for a particular trace tag,
stackstorm records the failure and emails an admin informing the admin of the
failure. By using a key with a TTL set on it, the workflow I've created to do
this is able to email the admin only on first failure of the action for a
particular trace tag, and when that action is "fixed", or when it runs
successfully (again, with respect to a trace tag).

The problem is, trace information is not available from within orquesta. (I
wrote the email sending workflow in orquesta.) I can get action execution id,
and I can get and set keys using the st2 stackstorm pack, but I can't get trace
information (such as trace tag) for the current action execution id.

It would be AMAZING if I could get trace information for a particular action
execution id in an orquesta workflow. Currently, I have to bake my
email-on-fix-or-failure workflow in other workflows that are responsible for
running the tasks with interesting failures and therein I explicitly pass the
name of the trace tag to the fix-or-failure email workflow. BUT, if I could get
trace tag information from within the notify workflow itself, I could simply
create a rule that triggered off of the core.st2.generic.actiontrigger
trigger type and just email fix-or-failure for ALL stackstorm actions on the
instance, without baking the fix-or-failure workflow into other workflows in
order to get it to work.

STEPS TO REPRODUCE

Alternative 1: make trace info available in the st2 pack

I could accomplish this by getting this info myself through the st2 pack:

1. Create a pack: mypack/
2. Create a workflow: mypack/actions/orq.yaml
3. In that workflow, put the following content:

tasks:
  get_trace_info:
    action: st2.traces_get
    input:
      execution_id: `{{ ctx().st2.action_execution_id }}`
    next:
      - publish:
        - trace_info: `{{ result().result.trace_info }}` 
        do: echo_info
  echo_info: 
    action: core.local
        cmd: echo `{{ ctx().trace_info.trace_tag }}`.

This is the most versatile alternative. I could get the trace info for the
current execution id shown above, or I could pass an execution id into the
workflow which points to an execution which failed, so that I could run an
email on it.

Alternative 2: Put trace info for a given execution into core.st2.generic.actiontrigger

Alternatively, it would also work for me to get the trace information from the
core.st2.generic.actiontrigger via the rule definition in jinja. An example
rule:

---
    name: "notify_first_failure_or_fix"
    pack: "mypack"
    description: "notify people when a first failure or fix happened on a trace tag"
    enabled: true

    trigger:
        type: core.st2.generic.actiontrigger
        parameters: {}

    criteria:
        trigger.action_name:
            type: "equals"
            pattern: "something.im.interested.in.catching.failure.on"
        trigger.status:
            type: "regex"
            pattern: "succeeded|failed"

    action:
        ref: "mypack.notify-fix-failure"
        parameters:
            trace_tag: "{{ trigger.trace_info.tag }}"

Alternative 3: It's just available via jinja or yaql

1. Create a pack: mypack/
2. Create a workflow: mypack/actions/orq.yaml
3. In that workflow, put the following content:

tasks:
  echo_info:
    action: core.local
    input:
        cmd: echo `{{ ctx().st2.trace_info.trace_tag }}`.

I'd still have to bake the notify workflow into all workflows using this
alternative, but at least I'm not having to pass the trace tag into the
workflow explicitly.

Start with the Orquesta workflow examples and the st2.traces_get and core.st2.generic.actiontrigger entry points described in the issue. Determine which of the three proposed access paths is appropriate, then verify that trace information is available for the current execution and for an explicitly supplied execution id.