Open Stack

Hello,
thank you very much for the feedback.

Ok, I have tried to go through the triggers an events.

Let me summarize, so we can confirm I understand it correctly:
======================================

The trigger:
--------------

- has a pattern - that is something like starting condition, that leads 
to creating a trigger
- has a criteria - that is the condition, that has to be fulfilled in 
some given timeout after
                          the trigger is created:
                          --- then it can run some action(triggered 
notification pipeline) and it saves the
                               trigger(so it has query-able history of 
the triggers)
                          --- or the timeout action ( optional 
expiration notification pipeline).

Questions
-------------

1. In the example in 
https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers
the pattern and criteria are a condition that are checking appearance of 
specific events.
What are the options for the conditions? What is the querying API?

2. Can the conditions be tied only to the events? Or also to samples and 
statistics, so I can build
similar queries and conditions, that alarms have?

3. If I have set e.g. trigger for measuring health of my 
baremetals(checking disk failures), I could just set
both conditions(pattern, criteria) the same, to observing some events 
marking disk failure, right?

If there will be disk Failures, it would create a trigger for each disk 
failure notification, right? So I could then
browse the triggers to check which resources had a disk failures?

What are the querying options over the triggers? E.g. I would like to 
get number of triggers of some type
on some resource_ids, from last month, grouped by project?

Summary
======

If the trigger pattern and criteria supports a general condition like 
Alarms do, I believe this could work, yes.

Otherwise it seems we should use Alarms(and Alarms Groups) for checking 
sample based alerts, and Triggers
for checking events(notifications) based alerts. So e.g. the health of 
hardware would be likely computed from
combination of Alarms and Triggers.


On 09/24/2013 03:48 PM, Thomas Maddox wrote:
> I think Dragon's BP for notification triggers would solve this problem.
>
> Instead of looking at it as applying a single alarm to several resources,
> you could instead leverage the similarities of the resources:
> https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers.
>
> Compound that with configurable events:
> https://blueprints.launchpad.net/ceilometer/+spec/configurable-event-defini
> tions
>
> -Thomas
>
> On 9/24/13 7:46 AM, "Julien Danjou" <julien at danjou.info> wrote:
>
>> On Tue, Sep 24 2013, Ladislav Smola wrote:
>>
>>> Yes it would be good if something like this would be supported. ->
>>> relation of alarm to multiple entities, that
>>> are result of sample-api query. Could it be worth creating a BP?
>> Probably indeed.
>>
>> -- 
>> Julien Danjou
>> # Free Software hacker # independent consultant
>> # http://julien.danjou.info
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130925/a28de92d/attachment.html>