Difference between revisions of "Heat/AutoScaling"
< Heat
Line 10: | Line 10: | ||
* AS Launch Config (heat/engine/resources/autoscaling.py) | * AS Launch Config (heat/engine/resources/autoscaling.py) | ||
* Cloud Watch Alarms (heat/engine/resources/cloud_watch.py, heat/engine/watchrule.py) | * Cloud Watch Alarms (heat/engine/resources/cloud_watch.py, heat/engine/watchrule.py) | ||
+ | |||
+ | ==== Dependencies ==== | ||
+ | |||
+ | Note the in template resource dependencies are: | ||
+ | |||
+ | *Alarm | ||
+ | ** Group | ||
+ | ** Policy | ||
+ | *** Group | ||
+ | **** Launch Config | ||
+ | **** [Load Balancer] - optional | ||
+ | |||
+ | This mean the creation order should be [LB, LC, Group, Policy, Alarm]. | ||
+ | |||
[[File:Current.png|none|Current architecture]] | [[File:Current.png|none|Current architecture]] | ||
Line 33: | Line 47: | ||
==== When a stack is created with these resources the following happens: ==== | ==== When a stack is created with these resources the following happens: ==== | ||
− | |||
− | |||
# LaunchConfig: it is just config storage | # LaunchConfig: it is just config storage | ||
# Group: the Launch config is used to create the initial number of servers. (note we need to start adding a tag to the server with probably the group name, this is used to aggregate the metrics in ceilometer) | # Group: the Launch config is used to create the initial number of servers. (note we need to start adding a tag to the server with probably the group name, this is used to aggregate the metrics in ceilometer) | ||
+ | # Policy: the policy is created in the new policy resource via a POST to the autoscaling service: TODO(radix;). We at this point know the AS-Group so we can pass a webhook to the AS service with the Group resource ID in it. It will need to provide the webhook/url to post alarm notifications to. | ||
+ | # Alarm: the alarm is created in Ceilometer via a POST (https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py). We pass it the above webhook. | ||
# ceilometer then starts collecting samples and calculating the thresholds. | # ceilometer then starts collecting samples and calculating the thresholds. | ||
+ | |||
+ | |||
+ | This mean the creation order should be [LB, LC, Group, Policy, Alarm]. | ||
+ | |||
==== When an alarm is triggered in Ceilometer the following happens: ==== | ==== When an alarm is triggered in Ceilometer the following happens: ==== |
Revision as of 06:19, 21 June 2013
Heat Autoscaling now and beyond
AS == AutoScaling
Now
The AWS AS is broken into a number of logical objects
- AS group (heat/engine/resources/autoscaling.py)
- AS policy (heat/engine/resources/autoscaling.py)
- AS Launch Config (heat/engine/resources/autoscaling.py)
- Cloud Watch Alarms (heat/engine/resources/cloud_watch.py, heat/engine/watchrule.py)
Dependencies
Note the in template resource dependencies are:
- Alarm
- Group
- Policy
- Group
- Launch Config
- [Load Balancer] - optional
- Group
This mean the creation order should be [LB, LC, Group, Policy, Alarm].
When a stack is created with these resources the following happens:
- Alarm: the alarm rule is written into the DB
- Policy: nothing interesting
- LaunchConfig: it is just storage
- Group: the Launch config is used to create the initial number of servers.
- the new server starts posting samples back to the cloud watch API
When an alarm is triggered in watchrule.py the following happens:
- the periodic task runs the watch rule
- when an alarm is triggered it calls (python call) the policy resource (policy.alarm())
- the policy figures out if it needs to adjust the group size, if it does it calls (via python again) group.adjust()
Beyond
- make the AS policy a service
- use ceilometer (pluggable monitoring)
Basically the same steps happen just instead of python calls they will be REST calls.
When a stack is created with these resources the following happens:
- LaunchConfig: it is just config storage
- Group: the Launch config is used to create the initial number of servers. (note we need to start adding a tag to the server with probably the group name, this is used to aggregate the metrics in ceilometer)
- Policy: the policy is created in the new policy resource via a POST to the autoscaling service: TODO(radix;). We at this point know the AS-Group so we can pass a webhook to the AS service with the Group resource ID in it. It will need to provide the webhook/url to post alarm notifications to.
- Alarm: the alarm is created in Ceilometer via a POST (https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py). We pass it the above webhook.
- ceilometer then starts collecting samples and calculating the thresholds.
This mean the creation order should be [LB, LC, Group, Policy, Alarm].
When an alarm is triggered in Ceilometer the following happens:
- Ceilometer will post a webhook to what ever we supply (I'd guess a url to the policy API)
- the policy figures out if it needs to adjust the group size, if it does it calls a heat-api webhook (something like PUT.../resources/<as-group>/adjust)
Authentication
- how do we authenticate the request from ceilometer to AS?
- is this a special unprivileged user "ceilometer-alarmer" that we trust?
- at some point we need to get the correct user credentials to scale in the AS group.