You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note The new syntax is not backward compatible, so before implementing it, we want to know your opinion first.
To enable the multichannel feature (see epic #596), we want to refactor the current BotKube configuration syntax and extend it with new properties.
Overview
Q: Why refactor? A: The BotKube already has a lot of great features, however, their way of configuration sometimes differs. We want to unify it and make it more self-describing and structured. Additionally, we want to enable further extensibility.
Q: What does the new syntax allow for? A: The new syntax not only groups the feature configurations and improves the readability. It also adds such features:
Defining kubectl (executor) permissions per channel—in particular, configuring what commands can be executed and in which Namespaces.
Routing notifications to individual channels. Example use cases:
a separate Slack channel for sending network errors and another channel for all error events that occur in the team-a Namespace
sending Pod's error events to Slack and, at the same time, notifying Elasticsearch of all events
Providing an easy way to define new notifiers (e.g. Sysdig) and executors (e.g. helm) in the future.
Q: Where can I find the new configuration proposal? A: The proposal is available on the #623 pull request.
Q: How can I provide feedback? A: You can get in touch with us in several ways:
join the feedback meeting, or
comment directly under this issue or the proposal pull request
CC'ing those of you above as you had indicated interest in multi-channel support in BotKube. Please feel free to leave your comments and reviews here and in the proposal.
Thanks to all for providing great feedback about the new BotKube's configuration syntax!
The feedback deadline was 5 days ago and there were only votes for yes 🎉 Today, the proposal was merged as accepted and the implementation has started 🏗️ The work will be tracked in #596.
Stay tuned for the upcoming release and the new multichannel support!
BotKube's new configuration proposal
To enable the multichannel feature (see epic #596), we want to refactor the current BotKube configuration syntax and extend it with new properties.
Overview
Q: Why refactor?
A: The BotKube already has a lot of great features, however, their way of configuration sometimes differs. We want to unify it and make it more self-describing and structured. Additionally, we want to enable further extensibility.
Q: What does the new syntax allow for?
A: The new syntax not only groups the feature configurations and improves the readability. It also adds such features:
kubectl
(executor) permissions per channel—in particular, configuring what commands can be executed and in which Namespaces.team-a
Namespacenotifiers
(e.g. Sysdig) andexecutors
(e.g.helm
) in the future.Q: Where can I find the new configuration proposal?
A: The proposal is available on the #623 pull request.
Q: How can I provide feedback?
A: You can get in touch with us in several ways:
Feedback Meeting
Date: 7th June at 5:00PM CEST. Convert to your timezone.
Meeting Link: Zoom
Meeting Agenda: Read, comment, or add agenda items in the meeting notes.
Calendar invite: Link to the Google invite.
Feedback
We are waiting for your feedback and information if the new approach supports your use cases.
We follow the lazy consensus approach to decision-making, which assumes that:
Deadline: 12th July (2 weeks from the day of announcement)
Timeline
The text was updated successfully, but these errors were encountered: