04abcf6ee4
The swift message actions can run into odd transient errors which can be "fixed" with simple retries. This change ensures all of our swift messaging tasks have retries and that those retries are all unified with a sensible delay. Change-Id: I555c21d5108f9227cacc9487bbb4cc45037caf03 Signed-off-by: Kevin Carter <kecarter@redhat.com>
156 lines
5.5 KiB
YAML
156 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
|
|
root_execution_id: 'UUID of the root execution',
|
|
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, root_execution_id => $.execution.root_execution_id, 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:
|
|
delay: 4
|
|
count: 16
|
|
input:
|
|
queue_name: <% $.queue_name %>
|
|
messages:
|
|
body: <% {type => $.type, payload => $.payload} %>
|
|
on-success: check_status
|
|
|
|
verify_container_exists:
|
|
workflow: tripleo.swift.v1.container_exists container=<% $.container %>
|
|
input:
|
|
create_container: true
|
|
retry:
|
|
delay: 4
|
|
count: 16
|
|
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
|
|
retry:
|
|
delay: 4
|
|
count: 16
|
|
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
|
|
retry:
|
|
delay: 4
|
|
count: 16
|
|
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
|
|
# verify_container_exists 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. Status:{} Message:{}".format($.get('status'), $.get('message')) %>): <% $.get('status') = "FAILED" %>
|