Difference between revisions of "Heat/Blueprints/FlexibleResourceGroup"

Latest revision as of 15:41, 24 July 2015

< Heat Launchpad Entry: HeatSpec:ScalableResourceGroup
Created: 26 July 2015
Contributors: Ahmed El-Khouly

Summary

OS::Heat::ResourceGroup provides a way to create several instances of identically configured nested resource; resources within the group are identifiable with with their index.
OS::Heat::ResourceGroup can only change number of resources in the group by changing the count property in the Heat template and perform a stack update of on the root stack.
OS::Heat::AutoScalingGroup/Policy provides for a resource group that can change in size(scale) by receiving signals controlling the size change.
There are some cloud applications that need a scalable resource group with the added ability to specify the exact resources to be add or removed from the group.

Release Note

TBD

Rationale

Some cloud applications need a new resource group with the following characteristics: 1) Create an initial number of identically configured nested resources.
2) Identify resources within the group using the index with the ability to specify a variable to be replaced by the index.
3) Add/Remove specific resource within the group by specifying the indices of involved resources.
4) Grow/shrink the group size (with a certain increment) when user defined triggers are met.

User Stories

1) Recreate a (failed) resource by adding/deleting the corresponding nested resource in the group.
2) Create new resources in increments when certain triggers are met.
3) Remove a number resources according to a predefined criteria(increasing or decreasing order of age or index).
4) Specify which resources to remove due to low load periods.

Assumptions

None.

Design

Define a new heat resource type: OS::HEAT::ScalableResourceGroup with the following properties:

   resource_def : Map
   Resource definition for the resources in the group. 
   Required property.
   Can be updated without replacement.

   index_var : String
   A variable that this resource will use to replace with the current index of a given resource in the group. 
   Updates cause replacement.
   Optional property, defaults to “%index%”.

   MAX_SIZE: Integer
   Maximum number of resources in the group.
   Optional Property
   Updates can cause creation/deletion of some resources according to de-grow policy
   INIT_SIZE: Integer
   Initial number of resources in the group at creation time.
   Optional property.
   Default value is 1.

   MIN_SIZE: Integer
   Min number of resources in the group.
   Optional property.
   Updates can cause creation/deletion of some resources according to de-grow policy

  DEGROW_Policy:String
  Controls which resources to remove when during de-grow.
  Optional property.
  Possible Values: "Index" or "Age"
  Default: "Index"

  DEGROW_Order:String
  Optional property.
  Possible Values: "Increasing" or "Decreasing"
  Default: "Decreasing"

ScalableResourceGroup class inherits from ResourceGroup:

   - Provide handle_signal implementation to receive signals to add/delete and grow/degrow signals.
   - Override create/validate/update/delete handlers.

@@ Line 1: / Line 1: @@
 < Heat
-Launchpad Entry: HeatSpec:rolling-updates
+Launchpad Entry: HeatSpec:ScalableResourceGroup<br />
-Created: 07 Feb 2013
+Created: 26 July 2015<br />
-Contributors: Clint Byrum
+Contributors: Ahmed El-Khouly<br />
-Contents
- [hide]
-Summary
-Release Note
-Rationale
-User stories
-Assumptions
-Design
-.1 OS::Heat::UpdatePattern
-.1.1 rolling
-.1.2 canary
-.1.3 depends_on
-.1.4 example
-Implementation
-.1 Update parent hooks
-.2 OS::Heat::UpdatePattern
-.3 heat.engine.update
-.4 UI Changes
-.5 Code Changes
-.6 Migration
-Test/Demo Plan
-Unresolved issues
-Summary[edit]
-While managing a large group of instances, I may want to roll out changes in topology and/or configuration to a limited percentage of these instances and then wait to see if those initial rollouts produced failures or successes before deploying a larger percentage. This is known as a "canary" deployment strategy, after the old mining practice of carrying a canary in a lantern to test for air quality.
-Release Note[edit]
+== Summary ==
-Multi-Instance resources may now associate themselvs with an OS::Heat::UpdatePattern via the update_pattern property. This will cause Heat to apply updates using a rolling or canary strategy.
+OS::Heat::ResourceGroup provides a way to create several instances of identically configured nested resource; resources within the group are identifiable with with their index.<br />
+OS::Heat::ResourceGroup can only change number of resources in the group by changing the count property in the Heat template and perform a stack update of on the root stack.<br />
+OS::Heat::AutoScalingGroup/Policy provides for a resource group that can change in size(scale) by receiving signals controlling the size change. <br />
+There are some cloud applications that need a scalable resource group with the added ability to specify the exact resources to be add or removed from the group.
-Rationale[edit]
+== Release Note ==
-With large scale deployments, updating configuration on all machines at once without testing may result in downtime. Being able to control the deployment will lead to more reliability for users who implement it.
+TBD
-User stories[edit]
-As an operations engineer I want to roll out a change to topology or configuration on a very large resource without the risk of significant downtime or error rates.
-Assumptions[edit]
-Design[edit]
-OS::Heat::UpdatePattern[edit]
-This will serve as a base class for two flavors, Rolling and Canary
-rolling_pattern:
-  type: OS::Heat::RollingUpdatePattern
-  properties:
-    min_in_service: 1
-    batch_size: 2
-canary_pattern:
-  type: OS::Heat::CanaryUpdatePattern
-  properties:
-    min_in_service: 1
-    batch_size: 2
-    growth_factor: 2
-rolling[edit]
-Updates will be done batch_size resources at a time. If the number of in-service resources would dip below min_in_service, then batch_size minus min_in_service updates will be initiated.
-canary[edit]
-Identical to rolling except batch_size is increased by multiplying with growth_factor after every successful batch.
+== Rationale ==
+Some cloud applications need a new resource group with the following characteristics:
+) Create an initial number of identically configured nested resources.<br />
+) Identify resources within the group using the index with the ability to specify a variable to be replaced by the index.<br />
+) Add/Remove specific resource within the group by specifying the indices of involved resources.<br />
+) Grow/shrink the group size (with a certain increment) when user defined triggers are met.<br />
-depends_on[edit]
+== User Stories ==
+) Recreate a (failed) resource by adding/deleting the corresponding nested resource in the group.<br />
+) Create new resources in increments when certain triggers are met.<br />
+) Remove a number resources according to a predefined criteria(increasing or decreasing order of age or index).<br />
+) Specify which resources to remove due to low load periods.<br />
-In order to determine how to proceed with the update, Heat will examine a resource's dependencies before updating it. Heat will call a hook in the parent which will allow the parent to return a wait condition.
+== Assumptions ==
+None.
-example[edit]
+== Design ==
+Define a new heat resource type: OS::HEAT::ScalableResourceGroup with the following properties:
+    '''resource_def : Map'''
+    Resource definition for the resources in the group.
+    Required property.
+    Can be updated without replacement.
-resources:
+     '''index_var : String'''
-  rolling_update_dbs:
+     A variable that this resource will use to replace with the current index of a given resource in the group.
-   type: OS::Heat::RollingUpdate
+    Updates cause replacement.
-   properties:
+    Optional property, defaults to “%index%”.
-     min_in_service: 1
-     batch_size: 1
-  db_server1:
-     type: OS::Nova::Server
-     depends_on: rolling_update_dbs
-    properties:
-      image: db-server-image
-      flavor: giant-server
-  db_server2:
-    type: OS::Nova::Server
-    depends_on: [ rolling_update_dbs , db_server1 ]
-    properties:
-      image: db-server-image
-      flavor: giant-server
-  canary_update_app:
-    type: OS::Heat::CanaryUpdate
-    properties:
-      min_in_service: 10
-      batch_size: 2
-      growth_factor: 2
-  appservers:
-    type: OS::Heat::ResourceGroup
-    depends_on: [ db_server2, canary_update_app ]
-    properties:
-      count: 20
-      resource_def:
-        type: OS::Nova::Server
-        properties:
-          image: my-cool-app
-          flavor: meh-server
-Implementation[edit]
-Update parent hooks[edit]
-Two new resource API hook points must be created which resource authors can implement to control updates of child-resources. They will be child_creating and child_updating. child_creating will be called as a child is being created to allow it to dynamically create any attributes that the child may fetch. For rolling updates this would be the update wait condition handle (or handles in the case of a group). child_updating will implement the logic which allows returning any wait conditions for Heat to wait on the child resource.
-OS::Heat::UpdatePattern[edit]
+    '''MAX_SIZE''': Integer
-This resource will create wait conditions for each dependent resource. For groups, it will need to create a wait condition and handle per group member. It will implement the update_child hook. On being notified that a child is being updated, it will examine the state of the current update and return all wait condition which must be completed before the child is allowed to move forward.
+    Maximum number of resources in the group.
+    Optional Property
+    Updates can cause creation/deletion of some resources according to de-grow policy
+    '''INIT_SIZE''': Integer
+    Initial number of resources in the group at creation time.
+    Optional property.
+    Default value is 1.
-heat.engine.update[edit]
+    '''MIN_SIZE''': Integer
-Changes must be made to call the child hooks, and to wait on the wait conditions returned by child_updating.
+    Min number of resources in the group.
+    Optional property.
+    Updates can cause creation/deletion of some resources according to de-grow policy
-UI Changes[edit]
+   '''DEGROW_Policy''':String
-N/A
+   Controls which resources to remove when during de-grow.
+   Optional property.
+   Possible Values: "Index" or "Age"
+   Default: "Index"
-Code Changes[edit]
+   '''DEGROW_Order''':String
-TBD
+   Optional property.
+   Possible Values: "Increasing" or "Decreasing"
+   Default: "Decreasing"
-Migration[edit]
+ScalableResourceGroup class inherits from ResourceGroup:
-Test/Demo Plan[edit]
+    - Provide handle_signal implementation to receive signals to add/delete and grow/degrow signals.
-Rollbacks should respect the update patterns as well, it is not entirely clear that this will "just work", though it should given the scheme, as a rollback is mostly an update in reverse.
+    - Override create/validate/update/delete handlers.
-Unresolved issues[edit]
-In a large instance group, failures may be common. Any failure conditions that can be expected and should not roll back an update should be identified and handled.
-Category: Spec
-Privacy policy About OpenStack Disclaimers Mobile view
- Attribution 3.0 Unported (CC BY 3.0)  Powered by MediaWiki