feat(config): autoreload on config changes

[SkalaNetworks]

This merge request adds a new flag to gobgpd to enable the detection of changes in the configuration file, triggering an auto reload.

This is especially useful in containerized environments, like Kubernetes, where pushing a new configuration through ConfigMaps will overwrite the content of the configuration file in the container, but not trigger a reload because GoBGP doesn't know about the changes.

The new flag is '-a' or '--config-auto-reload'. I'm simply using Viper's ability to detect new configurations and emulating a SIGHUP signal.

[mbanatt]

unsubscribe

…

On Mon, Oct 16, 2023, 16:00 SkalaNetworks ***@***.***> wrote: This merge request adds a new flag to gobgpd to enable the detection of changes in the configuration file, triggering an auto reload. This is especially useful in containerized environments, like Kubernetes, where pushing a new configuration through ConfigMaps will overwrite the content of the configuration file in the container, but not trigger a reload because GoBGP doesn't know about the changes. The new flag is '-a' or '--config-auto-reload'. I'm simply using Viper's ability to detect new configurations and emulating a SIGHUP signal. ------------------------------ You can view, comment on, or merge this pull request online at: #2722 Commit Summary - 15f7e62 <15f7e62> feat(config): autoreload on config changes File Changes (6 files <https://github.com/osrg/gobgp/pull/2722/files>) - *M* cmd/gobgpd/main.go <https://github.com/osrg/gobgp/pull/2722/files#diff-6d64976d21c93e71ca8d02274bd2b2f8ca91098346264daa8d2d95267392a85d> (63) - *M* docs/sources/getting-started.md <https://github.com/osrg/gobgp/pull/2722/files#diff-708a62b95fb251f9e3363ead878af6ac7a6c2dab372840fee8cbbb88c5dff080> (5) - *M* go.mod <https://github.com/osrg/gobgp/pull/2722/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6> (3) - *M* go.sum <https://github.com/osrg/gobgp/pull/2722/files#diff-3295df7234525439d778f1b282d146a4f1ff6b415248aaac074e8042d9f42d63> (4) - *M* internal/pkg/config/serve.go <https://github.com/osrg/gobgp/pull/2722/files#diff-ac415480aee79a58e5d5fc8eddd8b6b156d5e9fa7a6ab8857e73625f7c01f03e> (13) - *M* pkg/config/config.go <https://github.com/osrg/gobgp/pull/2722/files#diff-a3d824da3c42420cd5cbb0a4a2c0e7b5bfddd819652788a0596d195dc6e31fa5> (6) Patch Links: - https://github.com/osrg/gobgp/pull/2722.patch - https://github.com/osrg/gobgp/pull/2722.diff — Reply to this email directly, view it on GitHub <#2722>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5T2RPVXEOCFKYT7V3PU3X7WG7DAVCNFSM6AAAAAA6CXGPYKVHI2DSMVQWIX3LMV43ASLTON2WKOZRHE2DKOJZGQYDENA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[fujita]

Why sending a signal is difficult for reloading?

[SkalaNetworks]

@fujita not every deployment technology can send signals by itself on a config change, Kubernetes could theoretically send a signal through an HTTP webhook to gobgp (if it were to support it) to tell it to reload. We change the configuration of our bgp speakers quite often through GitOps, which means changing the config in the git results in a smooth automatic deployment with no manual operation.

For standard deployments (not through k8s), the alternative would be a script detecting the changes and pushing a signal to gobgp. With this PR, gobgp takes care of that by itself.