Ceilometer/blueprints/alarm-notification-details

Summary
It is useful to know why the state of the alarm changed. While this information is currently available in human-readable form, it is not available in machine-readable format.

Use Cases

 * forwarding the alarm notification to a different system
 * different reason representation than the current stringified one

Proposal
Current notification example: { "alarm_id": "0ca2845e-c142-4d4b-a346-e495553628ce", "current": "alarm", "previous": "ok", "reason": "Transition to alarm due to 1 samples outside threshold, most recent: 99.4" }

Proposed notification: { "alarm_id": "0ca2845e-c142-4d4b-a346-e495553628ce", "current": "alarm", "previous": "ok", "reason": "Transition to alarm due to 1 samples outside threshold, most recent: 99.4" "reason_data": { "type": "threshold", "disposition": "outside", "count": 1, "most_recent": 99.4 } }

Implementation
The details dictionary would be set by the alarm evaluator in Evaluator._transition and AlarmNotifier.notify would be called with an additional argument from Evaluator._refresh. Its contents would be different for each alarm type, e.g.

Threshold alarms: "reason_data": { "type": "threshold", "disposition": "outside", "count": 1, "most_recent": 99.4 }

Combination alarms: "reason_data": { "type": "combination", "alarm_ids": ["0ca2845e-c142-4d4b-a346-e495553628aa"] }