From ecfc2c215e5c44d641f63481907a7d13f73aacb4 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 31 Aug 2026 21:46:53 +0200 Subject: [PATCH] Point the plan at the survey, and name the likelier failure MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The conversion's detail is operational and names machines, so it lives in the mesh's knowledge base rather than in this repository: `migration/where-service-data-lives` for where every service's data actually sits, and `troubleshooting/db-password-frozen-at-first-init` for the lockout. This document says the rule; those say the specifics. The lockout is the finding worth carrying here, because it is worse than the one this plan was already guarding against and it is likelier. A database image consumes its password variable only when its data directory is empty. Everything keeps data on a persistent directory, so the role holds whatever password it was created with for ever; regenerate the variable and the application moves on while the database does not, permanently, because nothing reconciles it. Eight modules are in that state today and work only because nobody has regenerated their credential since their data directory was created. It was already documented in the knowledge base and my survey had missed it — found by searching, which is the argument for the knowledge base existing. --- 03-DESIGN/01-to-be/00-work-breakdown.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/03-DESIGN/01-to-be/00-work-breakdown.md b/03-DESIGN/01-to-be/00-work-breakdown.md index bbcd67a..6d7fdc4 100644 --- a/03-DESIGN/01-to-be/00-work-breakdown.md +++ b/03-DESIGN/01-to-be/00-work-breakdown.md @@ -161,6 +161,19 @@ service between systems. **So there is a step before any of this: read the current environment out of the old system**, because adoption means supplying those values and they live in its files today. +**And there is a failure worse than losing data, which is likelier.** A database image consumes its +password environment variable **only when its data directory is empty**. Everything here keeps its +data on a persistent directory, so the role holds whatever password it was created with, for ever. +Regenerate that variable and the application moves on while the database does not — permanently, +because nothing reconciles it. Eight modules are in that state today, working only because nobody +has regenerated their credential since their data directory was created. + +*Where the detail lives:* this is operational and names machines, so it is in the mesh's own +knowledge base rather than here — `migration/where-service-data-lives`, which surveys where every +service's data actually sits and what each stop or removal would cost, and +`troubleshooting/db-password-frozen-at-first-init` for the lockout itself. **This document says the +rule; those say the specifics.** + *Corrected 2026-08-31 — an earlier version of this paragraph made that sound more dangerous than it is.* A sealed secret is not unreadable; it is sealed **to the node**, which holds the private half and writes the plaintext into the module's own file. The value is there, on the machine, as an