Difference between revisions of "Heat/Blueprints/alarm-triggers-update"
m (Text replace - "__NOTOC__" to "") |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | ||
* '''Launchpad Entry''': [[HeatSpec]]:update-on-alarm-action | * '''Launchpad Entry''': [[HeatSpec]]:update-on-alarm-action | ||
* '''Created''': 08 Feb 2013 | * '''Created''': 08 Feb 2013 | ||
Line 16: | Line 16: | ||
== Rationale == | == Rationale == | ||
+ | |||
+ | Give the user power, har har har (Tim Allen anyone?) | ||
== User stories == | == User stories == | ||
+ | |||
+ | Implement an HA multi-inst stack. | ||
+ | * db on one instance | ||
+ | * webserver on another | ||
+ | * if the db-inst gets restarted, the webserver needs to know about it (reload it's config) | ||
+ | |||
+ | this is a case of using the OS::Heat::Restarter resource | ||
+ | |||
+ | Implement your own loadbalancer | ||
+ | * autoscaling group | ||
+ | * cloudwatch to step up/down the number of instances | ||
+ | * the loadbalancer needs to reload it's config with the new list of servers | ||
+ | |||
+ | this is a case of using the autoscaling grow action. | ||
== Assumptions == | == Assumptions == | ||
== Design == | == Design == | ||
+ | |||
+ | # After any non-user action that might cause a change the parsed-stack we call update stack. | ||
+ | # update stack will post new metadata that the instances can pull and run their hook scripts | ||
== Implementation == | == Implementation == | ||
=== UI Changes === | === UI Changes === | ||
+ | |||
+ | No changes needed to the template. | ||
=== Code Changes === | === Code Changes === | ||
Line 31: | Line 52: | ||
=== Migration === | === Migration === | ||
− | + | None | |
− | |||
− | |||
− | |||
== Test/Demo Plan == | == Test/Demo Plan == | ||
Line 41: | Line 59: | ||
== Unresolved issues == | == Unresolved issues == | ||
− | |||
− | |||
== BoF agenda and discussion == | == BoF agenda and discussion == |
Latest revision as of 23:29, 17 February 2013
- Launchpad Entry: HeatSpec:update-on-alarm-action
- Created: 08 Feb 2013
- Contributors:
Contents
Summary
To make templates more powerful (like what the loadbalancer resource does internally) we need to automatically trigger a stackupdate after a cloudwatch alarm action (one that causes changes to the stack).
The idea is that anything that might cause a change in a Ref() or GetAttr() will cause an update and therefore you could run hook scripts on your instance.
This is similar to juju signals (I believe).
Release Note
Rationale
Give the user power, har har har (Tim Allen anyone?)
User stories
Implement an HA multi-inst stack.
- db on one instance
- webserver on another
- if the db-inst gets restarted, the webserver needs to know about it (reload it's config)
this is a case of using the OS::Heat::Restarter resource
Implement your own loadbalancer
- autoscaling group
- cloudwatch to step up/down the number of instances
- the loadbalancer needs to reload it's config with the new list of servers
this is a case of using the autoscaling grow action.
Assumptions
Design
- After any non-user action that might cause a change the parsed-stack we call update stack.
- update stack will post new metadata that the instances can pull and run their hook scripts
Implementation
UI Changes
No changes needed to the template.
Code Changes
Migration
None
Test/Demo Plan
This need not be added or completed until the specification is nearing beta.
Unresolved issues
BoF agenda and discussion
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarizing what was discussed and note any options that were rejected.