Open andrewhowdencom opened 4 years ago
Should be well, and clearly documented -- probably in the .adoc
man files.
Also, the central configuration server -- might be worth revisiting to reason about A/B/N Patterns
Hot reload also applies to material like tls certificates. (Unsure how this works with Viper)
Treat configuration as a public API, with versions and a deprecation policy. Warn whenever deprecated configuration is used within the application (at least, for a while).
Perhaps protobuf definitions for configurations make sense? Unsure how to deserialize JSON into a protobuf primitive.
Configuration changes should be safe under load (perhaps by handing off requests, nginx style)
Configuration should not prevent the application (especially an RPC endpoint of some kind) from booting; only tweak its behavior. That means it should be safe to boot it without configuration.
Configuration should express its current version through telemetry (either as a timeseries, tagged as part of distributed tracing or logging the SIGHUP event / configuration reload specifically).
Should be handled by Viper largely.
Also, should automatically reload:
And be written to allow update via environment variables. Note: That is not always possible without a configuration registry of some kind -- something this application pattern is trying to avoid.
Moar thinking required. Maybe a "sighup" like behavior.