-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework Config Watcher and speed up configuration reload #774
Conversation
4acfd12
to
9100d3e
Compare
@pkosiec I was testing locally, I suggest to use following notation for botkube image to prevent apple m1 problem, plus your pr already generates docker image manifest for multiple archs.
I have apple m1 problem with config watcher, will fix and rerun the tests |
Oh sorry @huseyinbabal - I pushed my own image as there were problem with the CI build. But yeah, it was amd64 only. Now as I rebased the PR, please use the values you posted 🙂 Will update PR desc as well. Thanks! |
sure, I am also building k8s-sidecar for arm64, will push to ghcr |
Ah, yes, I forgot about making k8s-sidecar multiarch build 😞 I'm sorry. Original k8s-sidecar is multiarch indeed, but again, I built amd64 version only... Time to switch from Intel to M1/M2 as well 😄 Thank you Huseyin for help and sorry for troubles! |
No worries, now I managed to run everything with following additional config
|
99bd35c
to
e3c2dee
Compare
334533f
to
7501aa3
Compare
Hey @huseyinbabal
Hope we'll be ready to merge this soon 🚀 |
I retested with final changes, and it works 🚀 |
Description
Changes proposed in this pull request:
/reload
endpoint that restarts BotKube - it is called by the new Config Watchermake container-image-single
targetLimitations
The initial Config Watcher sync sometimes takes ~7-8 seconds on my machine, depending on the load. To prevent posting "Welcome" message by BotKube, I implemented wait for the synchronization in our app (with a timeout of 10s, this is a non-fatal error). That means BotKube start is slowed down now by a few secs.
Why? This avoids an issue when a user edits Source Bindings right after the BotKube "welcome" message and Config Watcher doesn't pick the change. See the video:
Screen.Recording.2022-09-28.at.16.05.01.mov
But, for a price of a slower start. Watch this:
Screen.Recording.2022-09-28.at.15.16.43.mov
That's why I made it configurable. Not sure what about the default values though. Does a user really edits Source Bindings within first 10 seconds after BotKube startup? I think that's an edge case we shouldn't spend too much time. I think the faster startup is more important. If you agree, that means maybe we should set the
initialSyncTimeout
to0s
. WDYT?Breaking changes
settings.configWatcher
option has been replaced withconfigWatcher.enabled: true
. Config Watcher now runs as a sidecar container. See possible configuration options on the Helm chart parameters page.To do
Testing
Check out the PR.
Export envs:
Install BotKube:
Edit Source Bindings on
frontend
orbackend
channel. You can use the UI.Observe BotKube behavior.
You can reinstall BotKube, this time with
configWatcher.initialSyncTimeout: 10s
and see how it works.Related issue(s)
Resolves #765