A great deal of our maintenance could be cut down if the application performed hot reloading of service check config options, checks.toml. This way, when the user updates the checks that should run, the server does not need to be restarted, instead, it just becomes aware of the new state it should be guided under.
The config lib we use, viper, supports this easily. Just be sure to avoid nasty race-condition scenarios, by preventing the vars the config is watching for from being reloaded in the middle of E.G. a round of service checks.
I don't believe this is possible to do for our web server options, config.toml, at least not in a way that does not interrupt service. Even if done programmatically, the server would still have to restart itself to do something like bind to a different interface or port for hosting.
A great deal of our maintenance could be cut down if the application performed hot reloading of service check config options,
checks.toml
. This way, when the user updates the checks that should run, the server does not need to be restarted, instead, it just becomes aware of the new state it should be guided under.The config lib we use,
viper
, supports this easily. Just be sure to avoid nasty race-condition scenarios, by preventing the vars the config is watching for from being reloaded in the middle of E.G. a round of service checks.I don't believe this is possible to do for our web server options,
config.toml
, at least not in a way that does not interrupt service. Even if done programmatically, the server would still have to restart itself to do something like bind to a different interface or port for hosting.