Open Stack

Comments inline ...

> Hi Liz,
> 
> The designs look really cool and I think that we should consider a couple of
> things (more related to the alarm’s implementation made at Ceilometer):
> 
> · There are combined alarms, which are a combination of two or more alarms.
> We need to see how they work and how we can show/modify them (or even if we
> want to show them)

+1

Combined alarms allow a meta-alarm to be layered over several under-pinning
alarms, with their state combined using logical AND or OR.
 
> · Currently, the alarms doesn’t have a severity field. Which will be the
> intention to have this? Is to be able to filter by “alarm severity”? Is to
> have a way to distinguish the “not-so-critical” alarms that the ones that
> are critical?

No such concept currently.

> · The alarms have a “list of actions” to be executed based on their current
> state. I think that the intention of that feature was to create alarms that
> could manage and trigger different actions based on their “alarm state”. For
> instance, if an alarm is created but doesn’t have enough data to be
> evaluated, the state is “insufficient data”, and you can add actions to be
> triggered when this happens, for instance writing a LOG file or calling an
> URL. Maybe we could use this functionality that to notify the user whenever
> an alarm is triggered and we also should consider that when creating or
> updating the alarms as well.

Alarm actions are currently either:

1. log the event

2. POST out to a webhook with a notification of the state change and related
   data (e.g. the recent datapoints).

In reality, all non-toy alarms would have action of form #2.

This is the form used by Heat for example when autoscaling is driven by
ceilometer alarms.

Re. the authorization of such actions in the alarm notification consumer,
one of two approaches are generally used:

1. pre-sign the webhook URL with the EC2 signer (this depends on the
   physical security of the URL being maintained, i.e. the URL not being
   leaked by ceilometer, or in this case horizon)

2. use the new-fangled keystone trusts

Heat originally used approach #1, but is changing over to approach #2 for Juno.

Actions are then associated with a target state (alarm, ok, insufficient_data)
with most alarm actions in practice being associated with the transition into
the alarm state. Multiple actions can be associated with a single target state.

By default, actions are only executed when the alarm state transition fires.

However, a continuous notification mode can be enabled on the alarm (such
that the actions are repeated on each alarm evaluation cycle as long as the
alarm *remains* in the target state).

> 
> 
> More related to Alarms in general :
> 
> · What are the ideas around the alarm notifications? I saw that your
> intention is to have some sort of “g+ notifications” but what about other
> solutions/options, like email (using Mistral, perhaps’), logs. What do you
> guys think about that?

Current only webhook notifications are supported.

But the idea for the last couple of cycles has been to leverage Marconi
SNS-style user-consumable notifications (email, SMS, tweets etc.) when &
if this becomes available.

> · The alarms could be created by the users as well.. I would add that CRUD
> functionality on the alarms tab on the overview section as well.

+1

Cheers,
Eoghan

> 
> 
> 
> Hope it helps
> 
> 
> 
> Regards,
> 
> H
> 
> 
> From: Liz Blanchard [mailto:lsurette at redhat.com]
> Sent: Tuesday, June 3, 2014 3:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Horizon] [UX] Design for Alarming and Alarm
> Management
> 
> 
> 
> 
> Hi All,
> 
> 
> 
> 
> 
> I’ve recently put together a set of wireframes[1] around Alarm Management
> that would support the following blueprint:
> 
> 
> https://blueprints.launchpad.net/horizon/+spec/ceilometer-alarm-management-page
> 
> 
> 
> 
> 
> If you have a chance it would be great to hear any feedback that folks have
> on this direction moving forward with Alarms.
> 
> 
> 
> 
> 
> Best,
> 
> 
> Liz
> 
> 
> 
> 
> 
> [1]
> http://people.redhat.com/~lsurette/OpenStack/Alarm%20Management%20-%202014-05-30.pdf
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>