Is it correct to run vector with --watch-config for zero-downtime config updates?

[chaporgin]

If no big NO for that exists, for example, the internal possibility of losing events, what is the way to do that?
I see at least rollWorkload should be set to false.
What would be the protection against an incorrect new config version? I imagine a liveness probe configured to HTTP GET - what?

[spencergilbert]

👋 hey @AntonyC,

--watch-config can be used in Kubernetes but it does have it's caveats. Updated ConfigMaps don't have a determinate time for when the the changes are propagated on disk, so rollouts happen "eventually". There are are some tools in the ecosystem that handle that in a more deterministic way but they're not part of the core platform.

Our Going to Production docs have several recommendations around event durability, but the short answer is using end-to-end acknowledgments and disk buffers.

What would be the protection against an incorrect new config version? I imagine a liveness probe configured to HTTP GET - what?

Depends on what you mean by "incorrect?" A valid configuration but not doing what you actually wanted it to, or an invalid config that Vector refuses to boot with?