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'] }

Add example of using native waitcondition resources
Add example of using native waitcondition resources

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
