In current Alarm implementation, Ceilometer will send back Heat an
'alarm' using the pre-signed URL (or other channel under development).
By the other channel, do you mean the trusts-based interaction?
We discussed this at the mid-cycle in Paris last week, and it turns out
there appear to be
On Mon, Jul 07, 2014 at 02:13:57AM -0400, Eoghan Glynn wrote:
In current Alarm implementation, Ceilometer will send back Heat an
'alarm' using the pre-signed URL (or other channel under development).
By the other channel, do you mean the trusts-based interaction?
Yes, Sir. Trusts and
Alarms in ceilometer may currently only be based on a statistics trend
crossing a threshold, and not on the occurrence of an event such as
compute.instance.delete.end.
Right. I realized this after spending some more time understanding the
alarm-evaluator code. Having 'Statistics'
On Mon, Jul 07, 2014 at 03:46:19AM -0400, Eoghan Glynn wrote:
Near the end of the Icehouse cycle, there was an attempt to implement
this style of notification-based alarming but the feature did not land.
After realizing 'Statistics' is not the ideal place for extension, I
took a
On Mon, Jul 07, 2014 at 02:13:57AM -0400, Eoghan Glynn wrote:
In current Alarm implementation, Ceilometer will send back Heat an
'alarm' using the pre-signed URL (or other channel under development).
By the other channel, do you mean the trusts-based interaction?
We discussed this at
On Mon, Jul 07, 2014 at 03:46:19AM -0400, Eoghan Glynn wrote:
Alarms in ceilometer may currently only be based on a statistics trend
crossing a threshold, and not on the occurrence of an event such as
compute.instance.delete.end.
Right. I realized this after spending some more
Hi,
In current Alarm implementation, Ceilometer will send back Heat an
'alarm' using the pre-signed URL (or other channel under development).
The alarm carries a payload that looks like:
{
alarm_id: ID
previous: ok
current: alarm
reason: transision to alarm due to n samples outside
