22 lines
1.6 KiB
Markdown
22 lines
1.6 KiB
Markdown
# Diagnosis — 2026-09-21
|
|
|
|
1. The constraint is real and where the report put it: a module requires a provision name once,
|
|
a pair credential is keyed on (name, consumer node, consumer module, provider), and the login
|
|
the vault derives is keyed on the (node, module) pair. Two secrets for one module and one vault
|
|
collide on every key.
|
|
2. The third question was answered by reading the ten modules. Six of the "two" cases hold two
|
|
names for one value or a value derived from another (an admin password and a token only ever
|
|
set from it, a relay user that is a fixed string beside the relay password). Those are one
|
|
secret each, and the module's own business to derive from. The "three or more" cases are
|
|
genuinely independent: a root certificate, its key and that key's password are three values
|
|
with three lifetimes.
|
|
3. So the answer is neither option as the report framed them. A module keeps one `secret`
|
|
provision per independent value, and needs a way to require the same provision name more than
|
|
once under distinct local names — the way `secrets:` already maps a provision to a path. That
|
|
is a manifest-vocabulary decision, and it moves the pair key: the credential must be keyed on
|
|
the local name, not the provision name, or the second pair overwrites the first.
|
|
|
|
**Located in:** the manifest's `requires`/`secrets` vocabulary (the catalogue parser) and the pair
|
|
credential's key (the controller's secret store). Not fixed here: the key change touches every
|
|
existing pair and belongs in a feature of its own, with a lab run against the vault bed.
|