197b8cc89b
Adds a simple example of using the native WaitCondition and WaitConditionHandle resources, which work in a similar way to the CFN compatible ones, but with more relaxed validation of data, and some additional helper attributes so you don't need to remember how to write the curl call in the template unless you need something unusual in the request. Change-Id: I2686d07e882781e93949ded9dd260161e4514a3b blueprint: native-waitcondition
80 lines
2.7 KiB
YAML
80 lines
2.7 KiB
YAML
heat_template_version: 2013-05-23
|
|
|
|
description: >
|
|
HOT template to demonstrate usage of the Heat native waitcondition resources
|
|
This is expected to work with any image containing curl and something which
|
|
runs the raw user-data script, e.g cirros or some image containing cloud-init
|
|
|
|
parameters:
|
|
key_name:
|
|
type: string
|
|
description: Name of keypair to assign to server
|
|
default: stack_key
|
|
image:
|
|
type: string
|
|
description: Name of image to use for server
|
|
default: cirros-0.3.2-x86_64-disk
|
|
flavor:
|
|
type: string
|
|
description: Flavor to use for server
|
|
default: m1.tiny
|
|
timeout:
|
|
type: number
|
|
description: Timeout for WaitCondition, depends on your image and environment
|
|
default: 300
|
|
|
|
resources:
|
|
wait_condition:
|
|
type: OS::Heat::WaitCondition
|
|
properties:
|
|
handle: {get_resource: wait_handle}
|
|
# Note, count of 5 vs 6 is due to duplicate signal ID 5 sent below
|
|
count: 5
|
|
timeout: {get_param: timeout}
|
|
|
|
wait_handle:
|
|
type: OS::Heat::WaitConditionHandle
|
|
|
|
instance1:
|
|
type: OS::Nova::Server
|
|
properties:
|
|
image: {get_param: image}
|
|
flavor: {get_param: flavor}
|
|
key_name: {get_param: key_name}
|
|
user_data_format: RAW
|
|
user_data:
|
|
str_replace:
|
|
template: |
|
|
#!/bin/sh
|
|
# Below are some examples of the various ways signals
|
|
# can be sent to the Handle resource
|
|
|
|
# Simple success signal
|
|
wc_notify --data-binary '{"status": "SUCCESS"}'
|
|
|
|
# Or you optionally can specify any of the additional fields
|
|
wc_notify --data-binary '{"status": "SUCCESS", "reason": "signal2"}'
|
|
wc_notify --data-binary '{"status": "SUCCESS", "reason": "signal3", "data": "data3"}'
|
|
wc_notify --data-binary '{"status": "SUCCESS", "reason": "signal4", "data": "data4"}'
|
|
|
|
# If you require control of the ID, you can pass it.
|
|
# The ID should be unique, unless you intend for duplicate
|
|
# signals to overrite each other. The following two calls
|
|
# do the exact same thing, and will be treated as one signal
|
|
# (You can prove this by changing count above to 7)
|
|
wc_notify --data-binary '{"status": "SUCCESS", "id": "5"}'
|
|
wc_notify --data-binary '{"status": "SUCCESS", "id": "5"}'
|
|
|
|
# Example of sending a failure signal, optionally
|
|
# reason, id, and data can be specified as above
|
|
# wc_notify --data-binary '{"status": "FAILURE"}'
|
|
|
|
params:
|
|
wc_notify: { get_attr: ['wait_handle', 'curl_cli'] }
|
|
|
|
outputs:
|
|
curl_cli:
|
|
value: { get_attr: ['wait_handle', 'curl_cli'] }
|
|
wc_data:
|
|
value: { get_attr: ['wait_condition', 'data'] }
|