Jump to: navigation, search

Heat/AutoScaling

< Heat
Revision as of 06:19, 21 June 2013 by Asalkeld (talk | contribs) (When a stack is created with these resources the following happens:)

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

This mean the creation order should be [LB, LC, Group, Policy, Alarm].


Current architecture

When a stack is created with these resources the following happens:

  1. Alarm: the alarm rule is written into the DB
  2. Policy: nothing interesting
  3. LaunchConfig: it is just storage
  4. Group: the Launch config is used to create the initial number of servers.
  5. the new server starts posting samples back to the cloud watch API

When an alarm is triggered in watchrule.py the following happens:

  1. the periodic task runs the watch rule
  2. when an alarm is triggered it calls (python call) the policy resource (policy.alarm())
  3. 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:

  1. LaunchConfig: it is just config storage
  2. 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)
  3. 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.
  4. 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.
  5. ceilometer then starts collecting samples and calculating the thresholds.

When an alarm is triggered in Ceilometer the following happens:

Current architecture


  1. Ceilometer will post a webhook to what ever we supply (I'd guess a url to the policy API)
  2. 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.