[Hawkular-dev] [Alerts] Requeriments for notifications and current work

[Jay Shaughnessy]

On 2/11/2015 4:40 AM, Lucas Ponce wrote:
> Hello,
>
> We have had several threads and discussion about notifications architecture, and we have also a small draft of the API in the current work.
> So, to unify all this conversations I am going to describe in the ML the current approach to summary all discussion around it.
>
> The conceptual requeriments are the following:
>
> Req1: Notifications will follow a plugin-based architecture
> -----------------------------------------------------------
>
> So, we can add/remove plugins into the system, without impact of rest of the components.

Is it correct to assume that for Hawkular a NotifierType Plugin will be 
an MDB listening on the Bus for published Alerts?  And that 
Hawkular-Alerts will supply some default NotifierType MDBs?

If that is true, then I think the NotifierType MDBs could self-register 
by sending a message to the Alerts Queue.  This would be as an 
alternative to using the Rest API to register, and then avoiding the 
need for a plugin to know any endpoint information.  It also avoids any 
disconnect that could happen if registration and deployment are done 
separately.  Did you have a different idea?

> Req2: There are two concepts: plugin (notifier type) and notifier
> -----------------------------------------------------------------
>
> A plugin will be responsible of a type of notifications
> (i.e. email-plugin, sms-plugin, snmp-plugin, etc...).
>
> A notifier is a representation of a destination with status about how it has to process the notification.
> A notifier can be reused in several triggers definitions.
> (i.e. in json pseudo-format
>        { notifierId: "email-admins-and-ceo",
>          properties: {
>                NotifierType: "email",
>                to: ["admin1 at corp.org", "admin2 at corp.org", "cep at corp.org"]
>                template: "Incident in %MSG% at %TIME%. Alert description: %ALERT_DETAILS% ..."
>                }
>        }
> )
>
> So, we can have several triggers definitions that will use the notifier "email-admins-and-ceo".

I don't think it should be required that a Trigger use a pre-defined 
Notifier.   I think it's OK that we could have pre-defined Notifiers, 
although it may be necessary then to ensure only a
proper subset are displayed, not just by Type but possibly tenant/user, 
etc.  So, the Trigger definer could select an existing Notifier, or 
supply an ad-hoc property-set.

I expect a NotifierType could have optional and required properties.  
Above, "to" would be required and "template" would likely be optional, 
with some default text.

> A plugin can have properties that are shared for all plugin.
> (i.e. the server/gateway used for email/snmp/sms).

I'm not sure I understand, but I'm not sure we need to have 
shared/global properties for the NotifierType plugins.  It seems a 
self-contained plugin may be best.

> A notifier can have specific properties.
> (i.e. list of destination, decoration of the message, other).
>
>
> Req3: There should be a central way where plugins are notifier are available
> ----------------------------------------------------------------------------
>
> New triggers definitions will be create through UI, so in the API we need to perform:
> - Get the list of notifiers created in the system (for an specific plugin or all plugins).
> - Link a notifier with a specific trigger(s) definition(s).
> - Create a new notifier of a specific type.

Right, we only need the first thing is we persist Notifiers.  We 
definitely need the ability to define an ad-hoc Notifier for a Trigger.


> Req4: Alerts engine sends alerts in a decoupled way
> ---------------------------------------------------
>
> Alerts engine is responsible to process data and to infer which alerts have to be sent.
> The alert engine should provide a decoupled way to send a notification through the notifier attached.

I agree.  The engine should be responsible for generating Alerts. For 
Hawkular the Alerts should be "tagged" with (perhaps JMS Headers for 
filtering) and likely be publish to a TriggeredAlerts topic for 
consumption by NotifierType plugins, and possibly anything else 
interested in generated alerts.

> ===
>
> There are also some technical requeriments that we are following in the current approach:
>
> TechReq1: Alerts engine should work in a decoupled way from other components
> ----------------------------------------------------------------------------
>
> The alerts engine implementation should not have a strong dependency with the bus component
> or any specific plugin implementation.
> So, the engine should be able to run in the whole hawkular architecture or it can be reusable
> for third party scenarios where other developers can create their own notifications architecture.

I think this is fine.  It means that some of the Hawkular-Alerts 
artifacts are independent of Hawkular "Kettle", although I don't think 
we need to split up the project repo.


> More details of the architecture proposed are under this article:
> https://developer.jboss.org/wiki/NotificationsPlugins-NotesAboutArchitecture
>
>
> TechReq2: Notifications plugins flow
> ------------------------------------
>
> A preliminar flow for the notifications plugins can be the following:
>
> - When a plugin is deployed, it should be registered, then it is available/visible for the API.
> - When a notifier is created through the UI using the API, a plugin should be notified.

Why is this?  Why does the plugin need to know about the defined Notifiers?

> - Main use case of the plugin is to listen for notifications messages to process its specific sent.

I'm not sure it should be listening for notification messages but rather 
published Alerts, which would contain/include the Notifier 
configuration/properties.

> TechReq3: Predefined notifiers
> ------------------------------
>
> Notifiers can be pre-created from an initialization configuration.

Like other definitions, it should be possible to import/export 
Notifiers, if we persist them.

> ===
>
> These are the requeriments used for the current draft of this area.
> The idea of this thread is to discuss about it to clarify/explain/modify it.
>
> After that I will try to collect all comments in a new article.
>
> Thanks in advance for your comments.
>

One last comment.  I wonder if we should maybe avoid RHQ's "Notifier" 
terminology.  It is OK, but it became sort of clunky when you would say 
that performing an operation on a resource was a Notification.   Perhaps 
"Action" may be a better term?  So we have Trigger Actions and Trigger 
Action Plugins.   Just a thought...