MIP-0001: Configuration and API#1
Conversation
jayrmotta
left a comment
jayrmotta
left a comment
There was a problem hiding this comment.
I like it a lot, my research says this has the best of a lot of different projects. I compared this proposal against: Braiins OS, ESP-Miner, LuxOS, systemd, Git, Open WRT, Kubernetes, Home Assistant, among others.
I also think this shouldn't be introduced at once, perhaps we can have intermediate steps and learn along the way as it seems a bit overwhelming at first.
One thing that came up in my research was the ability to know where a property that ended up in the saved config came from, as we would have several folders and multiple files per folder then what some software do is to offer an option to track properties that might be conflicting or taking a different precedence than intended.
Some other findings and opinions below in the comments.
| written by system services at boot and cleared on reboot. See below. | ||
| 4. Admin config files (`/etc/mujina/config.yaml` and | ||
| `/etc/mujina/config.d/*.yaml`), the administrator's space, never | ||
| written by a package. Conventional for a Unix daemon and kept for |
There was a problem hiding this comment.
Not sure what never written by a package means here
| ``` | ||
| PUT /api/v0/boards/e100-e2f56f9b/target_power_w | ||
| ``` | ||
|
|
||
| Setting one value is therefore a single PUT to that leaf. To change | ||
| several fields of a node in one atomic request, PATCH the node with a | ||
| partial document, which updates only the fields it names and leaves | ||
| the rest alone: | ||
|
|
||
| ``` | ||
| PATCH /api/v0/boards/e100-e2f56f9b | ||
| { "target_frequency_mhz": 525, "target_voltage_v": 1.15 } | ||
| ``` |
There was a problem hiding this comment.
What happens if some change in config result in a panic/crash or the hardware being unreachable in the network? We could put the device in a dangerous loop or get locked out of it remotely.
I've done some research and some communities adopt a stage/commit approach where changes done to the configs in runtime become staged but require an explicit commit/flush command to write them to disk. That way a hard reset would be enough to rollback the previous config and bring it back without some major intervention.
| A startup argument, something like `--delete-saved-config`, sets the | ||
| saved config aside before the daemon loads anything. Recovery is the | ||
| sharpest reason: a saved value that keeps the daemon from starting | ||
| leaves no running daemon to accept a delete, so the escape must be | ||
| reachable at startup. It also gives a clean reset, dropping every | ||
| runtime override to return the daemon to its file-and-default | ||
| configuration. Because it clears all overrides at once, it renames the | ||
| existing file aside rather than destroying it, leaving the user a copy | ||
| to restore what was good. Wholesale delete of saved config while the | ||
| daemon runs is a separate convenience and is deferred. |
There was a problem hiding this comment.
I see this as the last resort, if I'm a mining ops engineer and some device is misbehaving I would try other things before SSHing into it and "messing" with its internal state.
This is probably unrelated to the design decision of writing to the saved config on every live update, but it would be the only resort for operators that somehow locked themselves out of some device's API or even starting up properly.
2 participants
MIP-0001 sets out the requirements for Mujina's configuration system and REST API: one tree of named nodes unifying defaults, config files, environment variables, command-line arguments, and the API, with values that are readable, subscribable, validated, and persisted across restarts.
This PR is where the document is read and revised, so comments and line suggestions go here. For comfortable reading, the rendered view is easier than the diff: https://github.com/rkuester/mujina-mips/blob/mip-configuration-and-api/mip-0001-configuration-and-api.md
It grew out of reviewing the YAML-configuration PR (256foundation/mujina#36) on dev call #2 and the earlier "static config file" discussion (256foundation/mujina#23), which it subsumes.
Please poke holes.