Dynamic Config

Whenever a configuration option is used in a “one shot” fashion it could be dynamically fetched instead of requiring a process restart. This would give greater configuration control without restarts as well as provide a central configuration place (no need to update every configuration file on every server).

For example:

• The timeout for an operation is fixed at the start of each operation …
• … VS the database server requires a restart to change.

Why delay improving?

• Needs are yet unknown.
• Config will likely see large changes.

Potential improvement

1. Split the configuration object into two static objects:
   • Static configuration options are left in the existing file.
   • Dynamic configuration options are moved to a new file.
2. Change the dynamic configuration object to have a more dynamic API.
   • Possibly implement some wrapper type that DeRef to the requested type and is loaded when accessed (possibly cache in memory for sanity).
   • Possibly not so the cost/risk of dynamic lookup can be exposed.
   • Consider a dynamic configuration loader that returns a static view on the full dynamic configuration options vs dynamic loading of individual attributes.
   • Keep the stored format decoupled from the exposed interface (mainly the full configuration should be stored and picked from by the API).
   • Provide an official way to update dynamic configuration (replictl).
3. Update user code, if needed, to use a dynamic fetch API.
4. At startup, warn if the dynamic config loaded is not the same as the dynamic config file?

Downsides the new solution/idea

• Extra complexity in the code.
• Extra deployment complexity (need a configuration store of sorts).
• Less obvious configuration methods (upload configuration file to store? Changes done with replictl?)