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.
Fix proposed upstream: https://review.openstack.org/57423
Fix landed upstream: http://github.com/openstack/python-ceilometerclient/commit/7a5cbc14
Fix included in upstream python-ceilometerclient 1.0.7 release: https://pypi.python.org/pypi/python-ceilometerclient/1.0.7
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.
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