Difference between revisions of "Heat/AutoScaling"
< Heat
| Line 34: | Line 34: | ||
==== When a stack is created with these resources the following happens: ==== | ==== When a stack is created with these resources the following happens: ==== | ||
# Alarm: the alarm is created in Ceilometer via a POST (https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py) | # Alarm: the alarm is created in Ceilometer via a POST (https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py) | ||
| − | # Policy: the policy is | + | # Policy: the policy is created in new policy resource via a POST: TODO(radix;) |
# 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) | ||
| Line 52: | Line 52: | ||
* how do we authenticate the request from ceilometer to AS? | * how do we authenticate the request from ceilometer to AS? | ||
* is this a special unprivileged user "ceilometer-alarmer" that we trust? | * is this a special unprivileged user "ceilometer-alarmer" that we trust? | ||
| − | * at some point we need | + | * at some point we need to get the correct user credentials to scale in the AS group. |
Revision as of 05:02, 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)
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:
- Alarm: the alarm is created in Ceilometer via a POST (https://github.com/openstack/python-ceilometerclient/blob/master/ceilometerclient/v2/alarms.py)
- Policy: the policy is created in new policy resource via a POST: TODO(radix;)
- 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)
- 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.
