Support fine-grained configuration per channels for the same bot (e.g. Slack)

[pkosiec]

Overview

This issue is an epic and aggregates all the subtasks to finalize the complete feature.

Reason

There is a demand in community—5 open issues with a lot of reactions—to make the configuration more flexible in regards which notification should be collected and where to send.

Acceptance Criteria

• The resource_config.yaml and comm_config.yaml are merged into one, and can be provided multiple times. #643
• User is able to route notifications:
  • to individual channels without needing to run multiple deployments.
  • to a given channel based on the Kubernetes Namespace.
• User is able to define kubectl permissions per channel—in particular, configuring what commands can be executed and in which Namespaces.
• User-facing documentation is up-to-date.
• Unit-test/e2e test coverage is added to ensure no regression in the future.

To do

• Prepare design draft / proposal - @mszostok, see:
  • Add investigation doc about current syntax issues and possible fixes #623,
  • Add new configuration syntax proposal #626
• Gather community feedback about new design.
• Prepare a list of subtasks. Split them into:
  • required—those which need to be finished for MVP
  • follow-up—those which can be addressed later
• Start the asynchronous work to finish all required subtasks.

Related issues

This issue aggregates the feature requests from:

• Multiple Slack Channels #250
• Define the channel at the namespace level  #486
• Support using multiple Slack channels with different configuration #444
• Support communications per resource group #508
• Provide multiple channels  #542

All the tasks above will be eventually closed and the tracking of the feature will be done here.

[mszostok]

Findings

The #250 is not strictly related to this issue, see my #250 (comment).

However, in the backlog I spot new related issues:

• Support communications per resource group #508
• Provide multiple channels  #542

Additionally, almost 2 years ago, one of the contributor tried to solve this problem and submitted PR for that #291. Unfortunately, this pull request is too outdated and the work would need to be started from the ground.

Proposal

As a part of this task, I noticed that the configuration syntax has a few design issues. Because we need to extend that syntax, it would be good to also refactor it at the same time. Please take a look at:

• Add investigation doc about current syntax issues and possible fixes #623
• and Add new configuration syntax proposal #626

[mszostok]

Subtasks

• Resolve setting array values using environment variables #655 (@mszostok)

• Update BotKube with a skeleton for the new configuration syntax #656 (@mszostok)

• Add ability to enable notifications per communication platform #658 (@pkosiec)

• Implement support for handling multiple communicators and multiple channels #666 (@pkosiec)

  • Add support for:
    - logic for channel/index bindings
    - update documentation on botkube-docs
    - add required unit/e2e tests
    This can be done at the same time for all communicators or split.

• Add support for namespace settings in kubectl executor #663 (@mszostok)

  • Add logic to handle communicator bindings in kubectl #668

• Support routing notifications to a given channel based on Kubernetes Sources #676

  • Currently, it's only about kubernetes. Add support for:
    • new namespace.include/exclude property on the top level
    • update documentation on botkube-docs
    • add required unit/e2e tests

Can be done later:

• Refactor the Namespace config to simplify usage #679 @mszostok

• Add ability to configure specific recommendations during BotKube installation/upgrade #684 @pkosiec

[pkosiec]

Closing as all subtasks have been resolved.