Let a requirement be optional, binding only a provider that already runs (hq issue 166, ADR 0330) #281

Merged

mesh-admin merged 2 commits from fix/166-optional-requirement into main 2026-10-13 00:05:34 +00:00

Conversation 9 Commits 2 Files Changed 12

+870 -28

2 Commits

Author	SHA1	Message	Date
jochen	79a3396340	Store optional requirements beside a plain requires list (hq issue 166, review of #281) ... A controller older than optional requirements reads `requires` as names, and Inventory.Catalogue stops at the first manifest it cannot read: the long form stored inside `requires` would have left a rollback below this controller composing no machine. Stored, `requires` stays plain and the optional names sit in `optional-requires`, a key an older controller sets aside, leaving out only the module carrying it. A refusal of a hard requirement now names a module that wants it hard.	2026-10-13 01:53:18 +02:00
jochen	6ec4139871	Let a requirement be optional, binding only a provider that already runs (hq issue 166, ADR 0330) ... Making every soft dependency a provision made it hard: a mesh without influxdb could not assign grafana, and one with influxdb in its catalogue would install it for grafana. A requirement may now be written {"name": ..., "optional": true}. It resolves as a hard one when a provider is assigned or reachable, and is otherwise absent: never refused, nothing installed for it. Its binding, credential and only-when-bound files are left out, its ${bound:...|default:...} placeholders take their defaults, the module check refuses one that could render empty, and plan and node list it unbound.	2026-10-13 01:53:18 +02:00