-
Notifications
You must be signed in to change notification settings - Fork 50
Description
We've punted on this for a while but we need some kind of basic runtime configurability for Reconfigurator itself. The current motivation is #8244, where we want a boolean for disabling automatic runs of the planner. We may also want chicken switches for each of the things the planner does: fault tolerance-related changes, upgrade-related changes, mupdate-related changes, etc. At the same time, every configurable property here adds to the test matrix or creates divergence between what we ship and what we test, so we want to be careful in what we add here. (Maybe we should call it chicken_switches
?)
In terms of implementation, in today's watercooler we threw around the idea of one database table with one column for each configurable (allows it to be strongly typed) and using the pattern we've used elsewhere, where the table is logically a singleton but stores the history (used for bp_target, target release, etc.). There'd be a unique column called "version" or "generation". At any given time, the row with the max version is the current config. During planning, we slurp out the max-valued row as a single object. We'd need internal APIs for reading and writing the config (one API for the whole config is probably fine).
This has a few nice properties:
- we have the history of set values for debugging
- we have strong types for each configurable property
- changes can be made to several properties atomically, if that's desired
The work involved would be:
- database schema changes, maybe including populating initial values?
- Rust db model changes (schema.rs and model types)
- DataStore changes to fetch/update the values
- internal APIs
- omdb commands to read and update it