st2: Orquesta - Support output-on-error semantics

SUMMARY

In Mistral workflows there was an option for an output-on-error stanza. This block allowed workflow authors to return data in the event of an error within the workflow. We use this feature internally do things like:

Returning meaningful error messages from workflows
Returning the data that caused the error from a workflow
Returning a list of tasks that completed and those that failed within a variable (used for emails, ticketing systems and dashboards)

I would be open to a different mechanism (does not need to be output-on-error). But some way to replicate this functionality would be great!

ISSUE TYPE

Feature Request

STACKSTORM VERSION

$ st2 --version
st2 2.8.1, on Python 2.7.5

OS / ENVIRONMENT / INSTALL METHOD

OS = CentOS 7.5
Install method = puppet-st2

Example Mistral workflow

encore.preprovision:
  type: direct
  input:
    - domain_type
    - dns_domain
    - hostname
    - task_list: []
    - vm_os

  output:
    ip_address: "{{ _.ip_address | default(None) }}"
    task_list: "{{ _.task_list }}"
    vm_dns_records: "{{ _.dns_records | default(None) }}"
    vm_os_name: "{{ _.vm_os_name | default(None) }}"
  output-on-error:
    task_list: "{{ _.task_list }}"
    vm_dns_records: "{{ _.dns_records | default(None) }}"

  tasks:

...

    validate_ipam_hostname_unique:
      action: encore.mm_check_hostname
      input:
        hostname: "{{ _.hostname }}"
        dns_domain: "{{ _.dns_domain }}"
      publish:
        task_list: "{{ _.task_list + [{'name': 'validate_ipam_hostname_unique', 'status': 'SUCCESS'}] }}"
      publish-on-error:
        task_list: "{{ _.task_list + [{'name': 'validate_ipam_hostname_unique', 'status': 'ERROR', 'err_reason': 'Host already exists with name: ' + _.hostname + '.' + _.dns_domain }] }}"
      on-success:
        - validate_ad_computer_unique: "{{ _.vm_os.type == 'windows' and _.domain_type.lower() == 'domain' }}"
        - build_dns_records: "{{ _.vm_os.type != 'windows' or _.domain_type.lower() != 'domain' }}"
      on-error:
        - send_error_email
...

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 20 (18 by maintainers)

Most upvoted comments

So given the contention and misunderstanding on the subject, what I will be doing is to let orquesta process the output section when the workflow completes (regardless of success or failure). The values will be evaluated based on the final workflow context at time of workflow completion. If there is an evaluation failure on a key value pair, then the key value pair for the output will be skipped and an error entry will be appended in the result describing the evaluation error. I think this is sufficient in addition with the log schema in task transition. Uers should be able to take advantage with the change in output and log for troubleshooting and other advanced uses.

m4dcoder on Nov 8, 2018

To me, not giving users the option to publish output on workflow failure is counter intuitive and goes against common sense. Similar to running an executable and not getting any output at all if it fails for any reason, not even an exit code.

Failed workflows should let users publish any arbitrary variables with all context available. Even when implementing HTTP calls any framework lets you respond with non-200 status code and any headers and body added to it.

I can elaborate more on all this, but making Orquesta limited in this regards makes it way harder to migrate from Mistral.

Output from workflows is imperative for chatops aliases, when you need to pass various results from workflows to users. Re-writing mistral workflows so that instead of failing we go to a core.noop task where we publish variables and only after that they go to output is not feasible, let alone it masks their logical end of life in the UI and adds more tasks to workflows where not needed.

emptywee on Nov 8, 2018

@cognifloyd IMO, if the workflow fails, then there’s no output (or return value) from the execution. Think of this as a function call. If the function fails, it’ll return errors or print errors to console, but it doesn’t have a return value. Therefore, if the workflow author wants to output something for troubleshooting, the option for a log command that I propose above let’s user write messages and any extras. Since the placement of the log command is coupled with the condition of the task execution, it allows for user to determine when to write the log entries. Please remember that an error could also be a like HTTP where the execution is successful but with an error code. In this case, output-on-error or publish-on-error semantics won’t be able to catch them. Then finally, on completion of the workflow execution, regardless of success or failure, we will return the log entries in the workflow result in a log section like we do for errors.

m4dcoder on Sep 24, 2018

Here’s another variation. We can add a log entry to be included in the errors of orquesta workflow result. Orquesta workflow currently has list of errors and output in the result.

version: 1.0

description: A workflow demonstrating fail command.

tasks:
  task1:
    action: core.local
    input:
      cmd: '>&2 echo "boom!"; exit 1'
    next:
      - when: <% failed() %>
        publish:
          - err_msg: 'task1 failed'
          - extra_data: <% result().stderr %>
        log:
          - message: <% ctx(err_msg) %>
            extra: <% ctx(extra_data) %>
        do: fail

m4dcoder on Sep 12, 2018