Jump to: navigation, search

Difference between revisions of "Heat/Blueprints/lifecycle-callbacks"

 
Line 1: Line 1:
 +
Blueprint: https://blueprints.launchpad.net/heat/+spec/lifecycle-callbacks
 +
 
For this feature, Heat would provide a mechanism by which template authors can specify web hooks that would be called during various stages of a stack and/or resource's lifecycle. The user would be required to specify one or more hooks per lifecycle as well as optionally associated headers and body. Heat would parse nothing nor read responses from these calls, only react based on response code. A first pass at HOT syntax for this could be:
 
For this feature, Heat would provide a mechanism by which template authors can specify web hooks that would be called during various stages of a stack and/or resource's lifecycle. The user would be required to specify one or more hooks per lifecycle as well as optionally associated headers and body. Heat would parse nothing nor read responses from these calls, only react based on response code. A first pass at HOT syntax for this could be:
 
<pre>
 
<pre>

Latest revision as of 18:34, 24 April 2014

Blueprint: https://blueprints.launchpad.net/heat/+spec/lifecycle-callbacks

For this feature, Heat would provide a mechanism by which template authors can specify web hooks that would be called during various stages of a stack and/or resource's lifecycle. The user would be required to specify one or more hooks per lifecycle as well as optionally associated headers and body. Heat would parse nothing nor read responses from these calls, only react based on response code. A first pass at HOT syntax for this could be:

heat_template_version: 2013-05-23

description: |
  My first Heat template

parameters:

  foo_param:
    type: String

resources:

  my_server:
    type: OS::Nova::Server
    lifecycle_callbacks: # this is just to get the discussion going; this structure would be the same for stack-level callbacks
      create:
      - url: ttps://example.com/hooks/create
        on: [ PRE, SUCCESS, FAIL ] # pre-create, create complete, create failed 
        headers:
          X-Foo: { get_param: foo_param }
          X-Stack-Name: { get_param: OS::stack_name }
          X-Stack-Id: { get_param: OS::stack_id }
        body:
          str_replace:
            template: |
              state: {status}
              resource: my_server
            params:
              "{status}": { lifecycle_status: my_server } # new intrinsic function that can inspect the lifecycle state of a resource or stack
              "{stack_id}": {get_param: OS::stack_id }
        fail_on_error: false # Fail the stack operation if the hook returns an HTTP error code; default would be true
      update:
        (...)
      delete:
        (...)
      suspend:
        (...)
      resume:
        (...)
      abandon:
        (...)
      adopt:
        (...)
      snapshot: # this is a thing, right?
        (...)
    properties:
      name: my-server
      image: Ubuntu 14.04 LTS (Trusty Tahr)
      flavor: 2 GB Performance
            
outputs:

  "Server ID":
    value: { get_resource: my_server }
    description: The server id