When adding/changing configuration, make the meaning and lifecycle of defaults explicit and consistent.
Apply this standard:
- Unset vs default: If a value should be optional, represent it as unset by default and ensure all code paths preserve that (avoid implicit backstop defaults that change generated behavior, e.g., DNS records).
- Optional access consistency: Use the same “optional-aware” getter semantics across the codebase so you don’t accidentally convert an optional setting into a hardcoded default.
- Propagation clarity: In docs, state exactly when defaults apply (e.g., only on
create) and what needs to be restarted/stopped (daemon restart vs per-resource stop+restart).
- Intent-revealing structure: Organize TOML sections to match operational domains (so config layout communicates which component a setting affects).
Example (DNS optionality + TOML layout):
# Keep optional until user overrides
[dns]
# domain intentionally omitted (unset)
# domain = "test" # only set if user wants it
# Config docs requirement
- Defaults apply when creating resources: `container machine create ...`
- Existing resources are unchanged
- For `container machine set`, require: stop + restart the machine