Bug 1032554 - alarm update resets repeat_actions attribute, breaking heat autoscaling
alarm update resets repeat_actions attribute, breaking heat autoscaling
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-ceilometerclient (Show other bugs)
4.0
Unspecified Unspecified
high Severity medium
: rc
: 4.0
Assigned To: Eoghan Glynn
Kevin Whitney
: OtherQA
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-20 06:47 EST by Eoghan Glynn
Modified: 2016-04-26 11:27 EDT (History)
5 users (show)

See Also:
Fixed In Version: python-ceilometerclient-1.0.7-1.el6ost
Doc Type: Bug Fix
Doc Text:
In Ceilometer, updates to unrelated alarm attributes via the CLI caused the repeat_actions attribute to be set to False as an unintended side-effect. As a result, autoscaling actions would stop if an underpinning alarm was updated. This has been fixed so that the CLI now only updates the repeat_actions attribute when explicitly requested to do so. Now, autoscaling actions continue to occur after the underpinning alarms have been updated.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-19 19:37:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1253057 None None None Never

  None (edit)
Description Eoghan Glynn 2013-11-20 06:47:15 EST
Description of problem:

When an unrelated alarm attribute is updated via the CLI, the repeat_actions attribute is also set to False as an unwanted side-effect.

This breaks Heat autoscaling, which sets the repeat_actions to True for any ceilometer alarms it creates because it requires continuous notification as part of its implementation of the scale-up/down policy cooldown logic.

If such an alarm is subsequently modified, .e.g to tune the threshold, then autoscaling actions will no longer occur regardless of the alarm state.


Version-Release number of selected component (if applicable):

python-ceilometerclient-1.0.6-1.el6ost.noarch


How reproducible:

100%


Steps to Reproduce:
1. Create a new alarm:

   $ ceilometer alarm-threshold-create --name cpu_high --description 'instance running hot'  \
   --meter-name cpu_util  --threshold 70.0 \
   --comparison-operator gt  --statistic avg \
   --period 600 --evaluation-periods 3 \
   --alarm-action 'log://' \
   --query resource_id=INSTANCE_ID --repeat-actions True

2. Note that the repeat_actions attribute is reported as True in the response as expected.

3. Update the alarm threshold:

  $ ceilometer alarm-update -a $ALARM_ID --threshold 75.0

4. Note that the repeat_actions attribute is now reported as False in the response.


Actual results:

The repeat_actions attribute is set to False as an unwanted side-effect of updating another attribute.


Expected results:

The repeat_actions attribute should be left untouched when updating another attribute.
Comment 1 Eoghan Glynn 2013-11-20 06:50:19 EST
Fix proposed upstream:

  https://review.openstack.org/57423
Comment 3 Eoghan Glynn 2013-11-29 08:31:38 EST
Fix landed upstream:

  http://github.com/openstack/python-ceilometerclient/commit/7a5cbc14
Comment 4 Eoghan Glynn 2013-11-29 08:31:57 EST
Fix included in upstream python-ceilometerclient 1.0.7 release:

  https://pypi.python.org/pypi/python-ceilometerclient/1.0.7
Comment 6 Eoghan Glynn 2013-12-08 17:05:11 EST
This bug has been sanity tested only to verify it has been included as part of the Havana 2013.2 rebase to RHOS 4.0. If you find an issue with the bug, please reopen it.

Confirmed with python-ceilometerclient-1.0.8-1.el6ost that updating another alarm attribute does not result in the repeat_action attribute being set to false as a side-effect.
Comment 8 errata-xmlrpc 2013-12-19 19:37:37 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html

Note You need to log in before you can comment on or make changes to this bug.