b4053ad111
This should hopefully handle short, intermitent issues uploading to Swift. We currently use the same retry policy when sending Zaqar messages. Related-Bug: #1789680 Change-Id: Ibee6ba188585f80f0f7d136c81146096cb4432c2
147 lines
5.3 KiB
YAML
147 lines
5.3 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:
|
|
workflow: tripleo.swift.v1.container_exists container=<% $.container %>
|
|
input:
|
|
create_container: true
|
|
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: count=5 delay=1
|
|
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: count=5 delay=1
|
|
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"): <% $.get('status') = "FAILED" %>
|