search

Icinga / icinga-notifications

Icinga Notifications: new and improved notifications and incident management for Icinga (work in progress, not ready for production yet)
GNU General Public License v2.0
10 stars 0 forks source link

Channels: Custom Value Storage #232

Closed oxzi closed 3 months ago

oxzi commented 4 months ago

The channels are currently designed to be stateless. They are receiving notification events and contacts, but are unable to handle custom long-lived data without handling their own database. As an example, some channel might link Icinga Notifications with a ticket system and needs to map Icinga Notifications incident IDs to ticket IDs. In the current architecture, such a channel plugin would need to create this database by itself.

Giving channel plugins access to a key-value-store API to store their additionally needed state would ease channel development.

oxzi commented 3 months ago

At the moment, the RPC communication follows a request-response pattern unidirectional from Icinga Notifications to the channel plugin. Such a change would require altering this architecture, also allowing requests from the channel to Icinga Notifications.

When thinking about the effect of those changes, it would be possible to enable channels to perform further actions. For example, a channel could create an acknowledgement or downtime. This might be useful for a channel interacting with an "interactive" chat protocol, like XMPP, Matrix, or Telegram. Actually, I got the inspiration after watching Maxim Shchukin's Icinga Summit talk "Telegram Bot as a password-free monitoring front-end" about their interactive Telegram bot.

julianbrost commented 3 months ago

When thinking about the effect of those changes, it would be possible to enable channels to perform further actions. For example, a channel could create an acknowledgement or downtime.

By the way, that's an idea that's already floating around. This was also one of the considerations when implementing the RPC mechanism, many existing JSON-RPC implementations were ruled out because they wouldn't allow bidirectional calls.

julianbrost commented 3 months ago

This somewhat relates to #128 which I created a while ago, from that issue description:

it's probably necessary to provide some mechanism to notification plugins to keep some state

oxzi commented 3 months ago

This somewhat relates to #128 which I created a while ago, from that issue description:

it's probably necessary to provide some mechanism to notification plugins to keep some state

I missed this one, perhaps because it referred notifications and not channels or plugins in its name. But yes, reading #128 with this issue's focus, it seems very related. Thanks for bringing it up.

I am going to close this issue and use the other one, taking the liberty to change its title. Please feel free to change it back or to something even better.