tripleo-common/workbooks/messaging.yaml
Dougal Matthews 2f91f4c58e Standardise Workflow messaging and optionally persist messages
This workflow captures the boilerplate that is copied and pasted for Zaqar
messages. It also adds the ability to persist the messages in Swift.

This can be manually tested with:

    $ cat input.json
    {
        "type": "test",
        "queue_name": "tripleo",
        "plan_name": "overcloud",
        "execution": {
            "id": "UUID"
        }
    }
    $ openstack workflow execution create tripleo.messaging.v1.send input.json

Co-Authored-By: Steven Hardy <shardy@redhat.com>
Related-Bug: #1757372
Implements: blueprint config-download-workflows
Depends-On: I78b4fc7673a4039ed7ef32b16bb2850411f7fcc6
Change-Id: Ib854689a3e606f18db7354427918fa8043ac28e0
2018-05-02 15:44:45 +01:00

152 lines
5.5 KiB
YAML

---
version: '2.0'
name: tripleo.messaging.v1
description: TripleO Zaqar Workflows
workflows:
send:
description: >-
Send a message to a Zaqar queue and optionally persist it to Swift
This workflow sends a standard message to Zaqar (taking care of the
error handling and retry logic) and optionally persists the message
to Swift. The output of the workflow directly matches the input, this
means it can be used to send a message and set the output of the parent
calling workflow.
If plan_name is provided the message will be persisted to Swift. In a
container named "{plan_name}-messages". The swift objects will be
named:
{TYPE}/{TIMESTAMP}.yaml
If a deployment_status is provided, the top-level deployment_status.yaml
will also be updated, which will contain the deployment_status and the
related message.
The standard message format will be:
body: {
type: 'tripleo.workflow.name', # Matches the workflow name
payload: {
status: 'STATUS', # One of RUNNING, SUCCESS, FAILED
execution: {execution details}, # Deprecated and will be removed in the future.
execution_id: 'UUID',
message: "Human readable description",
< Arbitrary data. This should match the workflow output data >
}
}
Workflow Input:
queue_name - The Zaqar queue name to post to.
type - The message type, this should match the calling workflows name
execution - Details about the workflow execution. Should be passed by using <% execution() %>
status - Optional. The status of the message. SUCCESS/RUNNING/FAILED.
message - Optional. A human readable message to be included
payload - Optional. A dictionary output data to be sent in the message.
plan_name - Optional. The deployment plan name. This is used for the swift messages container.
deployment_status - Optional. If set the top-level deployment_status.yaml will be updated.
input:
- queue_name
- type
- execution
- status: 'SUCCESS'
- message: null
- payload: {}
- plan_name: null
- deployment_status: null
tags:
- tripleo-common-managed
output:
type: <% $.type %>
payload: <% $.payload %>
tasks:
merge_payload:
on-success:
publish:
branch:
# The payload with arbitrary keys is merged with the status, message and execution.
payload: <% {status => $.status, message => $.message, execution => $.execution, execution_id => $.execution.id, plan_name => $.plan_name, deployment_status => $.deployment_status} + $.payload %>
next: prepare_messages
prepare_messages:
on-success:
publish:
branch:
swift_message: <% {type => $.type, payload => $.payload} %>
deployment_status_message: <% {deployment_status => $.deployment_status, workflow_status => {type => $.type, payload => $.payload}} %>
container: <% "{0}-messages".format($.plan_name) %>
next: branch_workflow
# It should be possible for this to happen in the next section above, but
# there seems to be a Mistral bug... to be confirmed...
branch_workflow:
on-success:
- send_message
- complete_swift: <% not bool($.plan_name) %>
- verify_container_exists: <% bool($.plan_name) %>
send_message:
action: zaqar.queue_post
retry: count=5 delay=1
input:
queue_name: <% $.queue_name %>
messages:
body: <% {type => $.type, payload => $.payload} %>
on-success: check_status
verify_container_exists:
action: swift.head_container container=<% $.container %>
on-error:
- create_container
on-success:
- wait_for_swift: <% not bool($.deployment_status) %>
- persist_to_swift_plan_latest: <% bool($.deployment_status) %>
- persist_to_swift
create_container:
action: swift.put_container container=<% $.container %>
on-success:
- wait_for_swift: <% not bool($.deployment_status) %>
- persist_to_swift_plan_latest: <% bool($.deployment_status) %>
- persist_to_swift
persist_to_swift:
action: swift.put_object
input:
container: <% $.container %>
obj: <% "{0}/{1}.yaml".format($.type, now().format("%Y-%m-%d_%H:%M:%S")) %>
contents: <% yaml_dump($.swift_message) %>
on-success: wait_for_swift
persist_to_swift_plan_latest:
action: swift.put_object
input:
container: <% $.container %>
obj: <% "deployment_status.yaml" %>
contents: <% yaml_dump($.deployment_status_message) %>
on-success: wait_for_swift
wait_for_swift:
# We want persist_to_swift and either persist_to_swift_plan_latest or
# create_container to join here. Two of the three tasks.
join: 2
on-success: complete_swift
complete_swift:
on-success: check_status
check_status:
# We want both complete_swift and send_message to join here. This means
# that zaqar and swift (if enabled) will all be finished.
join: all
on-complete:
- fail(msg="Workflow failed due to message status"): <% $.get('status') = "FAILED" %>