Looks like it is getting replaced. (I'm disappointed in the 44 of you that want to give a hostile company tons of free labor. Do better. )

If anyone else uses
#Botkube and missed the announcement, sorry to be the bearer of bad news: github.com/kubeshop/botkube/releases/tag/v1.9.0

I already implemented about 60% of the "event watcher" pipeline in
#nodered so maybe I'll just finish that out. I needed nodered anyway because Botkube's webhook "support" is total amateur hour. If I had to guess, I would say it is an internal structure they just throw at the endpoint with no documentation. It changes, sometimes dramatically, from version to version.

Anyone know of a better event monitor for
#k8s #homelab #monitoring? Things like "{sts/deploy} not progressing" or "crash-loop backoff". I've got alertmanager, but it has gaps.

(edit to say '44' since there are 40 people who want to kick it down the road until it becomes an emergency)
Release v1.9.0 · kubeshop/botkube

What's Changed Botkube is introducing new plugins with advanced functionality that will be part of the Botkube Team and Enterprise packages. These advanced plugins require cloud services provided b...

GitHub

#selfhosted people using botkube, be aware that v1.9.0 removes some of the plugins (well, most of the plugins) that make botkube actually useful.

To continue using said plugins, you need an account on their cloud and you need to run botkube in their cloud (which, goes without saying, you have to provide a kubeconfig to be stored *in their cloud* for your kubernetes cluster).

https://github.com/kubeshop/botkube/issues/1399

#kubernetes #botkube

Helm plugin missing from plugins-index.yaml for 1.9.0 · Issue #1399 · kubeshop/botkube

Description Comparison of plugins-index.yaml for 1.8.0 vs 1.9.0 shows the following: jon@host:~/git/botkube$ yq .entries[].name ../plugins-index-1.8.0.yaml "exec" "helm" "kubernetes" "argocd" "gith...

GitHub
Turns out #nodered has several decent K8S connectors that can be used to do the whole thing without #botkube or #n8n. (And since I already had half of the Botkube parsing logic in #nodered for comparison, it was trivial to adapt.)

Botkube is on my radar today because every single release breaks
something about the generic webhooks, in addition to making undocumented changes to the undocumented format. As I said above, Botkube is a very hard road if you aren't using Slack or Teams or Discord.

I won't get "recommendations" but I don't think it will matter. The only one I ever saw was "don't use the latest tag" and I can add that manually if I miss it..

Also
#nodered has fed me zero fake tabs, missing configurations or upgrade advertisements.

#Kubernetes question for the fedi:

How do you convert webhook formats in a #homelab environment? For example, converting #botkube 'generic webhook' payload to feed #gotify

Lots of people seem to use #nodered, but that is a lot for a json transform.

Difficulty: It is part of the alerting pipe, so it should be as durable as possible. (As durable as something running on the same infra can be.)

I saw https://github.com/adnanh/webhook with simple python or curl scripts, but even with #defenseindepth (networkpolicy, securitycontext, etc) shell scripts seem hacky at best and a Bad Idea at worst.

Some form of #serverless would probably work, but that means finding, installing and learning a new #framework that hopefully won't become a huge headache in a week or a year.

The old #housebrain uses git-backed #nodered and it is a huge pain to maintain. (Mostly thanks to my design.) I'm doing it better this time.

(#boost)
#k8s #k3s #selfhosted

GitHub - adnanh/webhook: webhook is a lightweight incoming webhook server to run shell commands

webhook is a lightweight incoming webhook server to run shell commands - adnanh/webhook

GitHub