Difference between revisions of "Heat/Blueprints/lifecycle-callbacks"
< Heat
Randall Burt (talk | contribs) |
Randall Burt (talk | contribs) |
||
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