Jump to: navigation, search

Difference between revisions of "Heat/Blueprints/alarm-triggers-update"

 
m (Text replace - "__NOTOC__" to "")
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
__NOTOC__
+
 
* '''Launchpad Entry''': [[HeatSpec]]:multi-publisher
+
* '''Launchpad Entry''': [[HeatSpec]]:update-on-alarm-action
 
* '''Created''': 08 Feb 2013
 
* '''Created''': 08 Feb 2013
 
* '''Contributors''':  
 
* '''Contributors''':  
  
 
== Summary ==
 
== 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).
  
Describe the change in general terms.
+
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 ==
 
== Release Note ==
  
 
== 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 26: Line 52:
 
=== Migration ===
 
=== Migration ===
  
Include:
+
None
* data migration, if any
 
* redirects from old URLs to new ones, if any
 
* how users will be pointed to the new way of doing things, if necessary.
 
  
 
== Test/Demo Plan ==
 
== Test/Demo Plan ==
Line 36: Line 59:
  
 
== Unresolved issues ==
 
== Unresolved issues ==
 
This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
 
  
 
== 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:

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

  1. After any non-user action that might cause a change the parsed-stack we call update stack.
  2. 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.