Difference between revisions of "Heat/AutoScaling"
< Heat
(→When a stack is created with these resources the following happens:) |
|||
Line 52: | Line 52: | ||
# 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. | # 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. | ||
− | |||
− | |||
− | |||
− | |||
==== 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.
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.