Repository navigation
docs(#3201): step 1 landed, and it is inert — a helm upgrade never dropped the inline env - #3383
Merged
meshweaver-cloud[bot] merged 2 commits intoSep 6, 2026
Conversation
…opped the inline env Records what Systemorph/Memex#180 actually landed (the Key Vault CSI mapping for PluginCatalog__RegistryToken on both portals) and corrects the reasoning that PR carried. #180 argued the hand-applied inline `env:` is absent from helm's stored manifest and would therefore be dropped by the next `helm upgrade`, with a latent credential outage inferred for memex-cloud. Both are false — and this page already says why, four sections up: helm's three-way merge removes only what helm previously owned (measured 2026-09-03 on v3.21.1 and v4.2.4, with a positive control). The real mechanism is the shadow this page names: the inline entry outranks every envFrom, so the vault copy stays dead until step 3 deletes it, and step 1 changes nothing an operator can observe on the pod. Also date-qualifies the "There was never a Key Vault copy" bullet, which was measured 2026-09-04 and stopped being true on 2026-09-06. Refs #3201 #3374 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The updated section contains an internal inconsistency in the documented Key Vault secret object name (memex-PluginCatalog-RegistryToken vs PluginCatalog-RegistryToken) that could mislead operators applying the remediation steps.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Updates the ChartDriftSemantics documentation to record that “step 1” of the plugin-registry token cleanup has landed, and to correct the previously stated (incorrect) claim that a subsequent helm upgrade would drop a hand-applied inline env: entry.
Changes:
- Date-qualifies the “there was never a Key Vault copy” statement to reflect the new vault state after step 1.
- Adds a dated note explaining why step 1 is operationally inert on the running pod and clarifies Helm’s three-way-merge behavior.
File summaries
| File | Description |
|---|---|
| src/MeshWeaver.Documentation/Data/Architecture/ChartDriftSemantics.md | Adds dated clarifications about Key Vault state and Helm drift semantics for the plugin registry token cleanup steps. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+164
to
+166
| **Step 1 landed 2026-09-06** (`Systemorph/Memex` [#180](https://github.com/Systemorph/Memex/pull/180)): | ||
| each portal's in-use key is now in the `Systemorph` vault — `PluginCatalog-RegistryToken` for `memex` | ||
| and `memexcloud-PluginCatalog-RegistryToken` for `memex-cloud` — and both `values.<env>.public.yaml` |
Contributor
Contributor
Contributor
Contributor
Contributor
Step 1 was written 2026-09-04 prescribing `memex-PluginCatalog-RegistryToken`; what was created on 2026-09-06 is `PluginCatalog-RegistryToken` (no prefix) for memex. The step now names the real objects, and the dated note says the block renders NEW SecretProviderClasses (`memex-portal-keyvault`, `memexcloud-portal-keyvault`) rather than appending to the hand-made `memex-kv` / `memexcloud-portal-ai-secrets` — so an operator applying the remediation cannot aim at the wrong secret name or the wrong class. Refs #3201 #3374 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs only. Records what
Systemorph/Memex#180landed for #3201, and corrects the reasoning that PR carried into the private repo and into #3201's comment thread.The wrong claim
#180 argued that the hand-applied inline
env:carryingPluginCatalog__RegistryToken"is not in helm's stored manifest, so the nexthelm upgradedrops it", and inferred a latent credential outage onmemex-cloud— the namespace where the inline entry is the only copy on the pod.Both are false, and this page already says why, four sections up: helm's three-way merge removes only what helm previously owned — measured 2026-09-03 on v3.21.1 and v4.2.4 against a deliberately drifted release, with a positive control (the chart's genuine changes landed while a live-only inline
env:, a live-only ConfigMap key, an inline env duplicating a chart key and a live probe field all survived).The real mechanism is the shadow this page already names: the inline entry outranks every
envFrom, so the vault copy stays dead until step 3 deletes it, and step 1 changes nothing an operator can observe on the pod.Changes to
ChartDriftSemantics.mdPluginCatalog-RegistryTokenformemex,memexcloud-PluginCatalog-RegistryTokenformemex-cloud), plus the correction above stated explicitly, so the next reader does not re-derive the wrong answer from the PR that landed it.Step 1 is still correct and worth having: it makes the vault the declared source of truth and puts the value in a committed source. It is just inert on the pod, and not urgent.
No mechanism claim on this page changed — the measured rule and the per-class triage were already right here. The counterpart correction is
Systemorph/Memex#181.Verification
Refs #3201 #3374