Botkube Automation

[brampling]

A user must be able to configure an automation action based on a selected incoming event. This allows the user to perform automatic problem resolution, automatically initiate early troubleshooting steps, and otherwise enhance their time to recovery when an issue occurs. Currently users are notified of events through a configured channel and must take all action manually either through Botkube or through other CLI and UI-based tools.

AC

• Users can configure Botkube to watch for a specific event type
• Users can filter the watched events
• Users can configure an executor action to trigger on the selected/filtered event (in other words, a given event triggers a given executor command).
• Relevant event details and metadata are passed to the executor action (i.e. pod name on a pod-related event)
• Configured actions are executed when the configured event occurs
• A notification is sent to the appropriate channel when an automated action occurs (ideally through the k8s event system and not only through Botkube, so that the event is logged in the k8s infrastructure)
• Configured actions can be enabled/disabled dynamically through chat commands (e.g. @Botkube list/enable/disable automations)
• Consult the configuration draft with @lpetkov

[pkosiec]

Notes

• Executed command could be defined in config as a Go template string, rendered with events.Event object in context:

  # (...) for a given event the following command will be executed:
  command: "kubectl get {{.Event.ResourceType}} -m {{.Event.Namespace}} {{.Event.Name}}" # namespace and name are from the `Event` object

• The output is sent to the channel with a header that the command was executed by automation rule.

• Making the events.Event generic is out of scope for now, it will be done as a part of Event Manager Extensibility #649. But take this into account to make sure the config could support other events in a generic way

[ezodude]

In the acceptance criteria:

Users can filter the watched events

I'm not sure what this means??

[brampling]

For example, the previous AC means we would watch for "pod create" events. This AC means I can filter those pod create events. Maybe I only want to trigger on a pod create matching a specific name pattern, or a specific annotation.

[ezodude]

@brampling added a ticket to cover this: #832