Uh oh!
There was an error while loading. Please reload this page.
Fixes from problematic pr worth keeping - #415
Closed
OisinKyne wants to merge 4 commits into
Closed
Conversation
OisinKyne
commented
May 4, 2026
ContributorAuthor
favouring #417 and upstreams |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem to be solved
PR #413 is satisfactory and
slightly cleaner than what we
did. Compared side-by-side:
Equivalent or better:
architecture (image's
/opt/hermes/.venv)
v2026.4.30 (we kept the older
pin)
check ("missing binary" /
"missing extras") — slightly
more defensive than what we had
usage strings made
runtime-neutral
call added to Hermes restore —
we missed this; restore would
have left a stale
wallet-metadata ConfigMap in
the cluster after a wallet swap
backup/restore tests for the
Hermes path — we didn't write
these
Not in #413 (consistent with
the PR body's note that they
punted on these intentionally
or scope-wise):
--force-conflicts on
helmDefaults for both
helmfiles. PR fix: simplify Hermes recreation lifecycle #413 says "main
has the managed-fields
mitigation" — but we now know
the
releaseLiteLLMConfigOwnership
mitigation doesn't actually
work (you hit
before-first-apply on it). So
the SSA conflict on
litellm-config and
remote-signer-keystore-password
is unaddressed by main + fix: simplify Hermes recreation lifecycle #413
together.
into both branches of
K3dBackend.Up (so stopped
registry caches come back on
every up, not just on cluster
create)
ensureDevRegistry when start
fails because the container's
referenced Docker network was
reaped
Recommendation: merge #413
as-is, then branch fresh from
main with those three
leftovers. They're tightly
scoped, mutually independent,
and not adjacent to the
bootstrap-rip-out diff.
Ordering inside the new branch:
Order: 1
Fix: helm SSA force-conflicts
Files: internal/embed/infrastru
cture/helmfile.yaml,
internal/hermes/hermes.go:gen
erateHelmfile
───────────────────────────────
─
Order: 2
Fix: Registry restart on every
up
Files: internal/stack/backend_k
3d.go:Up
───────────────────────────────
─
Order: 3
Fix: Registry orphaned-network
recovery
Ordering inside the new branch:
┌─────┬──────────────┬──────────────────────────────────────┐
│ Ord │ Fix │ Files │
│ er │ │ │
├─────┼──────────────┼──────────────────────────────────────┤
│ │ helm SSA for │ internal/embed/infrastructure/helmfi │
│ 1 │ ce-conflicts │ le.yaml, internal/hermes/hermes.go:g │
│ │ │ enerateHelmfile │
├─────┼──────────────┼──────────────────────────────────────┤
│ │ Registry │ │
│ 2 │ restart on │ internal/stack/backend_k3d.go:Up │
│ │ every up │ │
├─────┼──────────────┼──────────────────────────────────────┤
│ │ Registry │ │
│ 3 │ orphaned-net │ internal/stack/dev_registry.go:ensur │
│ │ work │ eDevRegistry │
│ │ recovery │ │
└─────┴──────────────┴──────────────────────────────────────┘
I'd also drop the releaseLiteLLMConfigOwnership from main in
that same fresh branch — it's load-bearing today (per the PR
body), but with --force-conflicts it becomes dead code, same
reasoning as we worked through earlier today.
One nit on #413 worth a one-line review comment, not blocking:
the init-hermes-data container in #413 runs as the pod default
user (uid 10000) — which is fine for the mkdir + state.db path,
but if the PVC has any pre-existing root-owned content from
won't bite anyone in practice but worth flagging.
Summary
All five tasks complete, build clean, tests passing.
Summary of changes on oisin/413-1:
File: internal/embed/infrastructure/helmfile.yaml
Change: New helmDefaults.args: ["--server-side=true",
"--force-conflicts"] block at the top
────────────────────────────────────────
File: internal/hermes/hermes.go (generateHelmfile)
Change: Same helmDefaults block in the generated per-instance
Hermes helmfile
────────────────────────────────────────
File: internal/stack/backend_k3d.go (Up)
Change: Hoisted ensureDevRegistries out of the else-only branch
so it runs on every Up — stopped registry containers come
back
even when the cluster is just being restarted
────────────────────────────────────────
File: internal/stack/dev_registry.go (ensureDevRegistry)
Change: When docker start fails on an existing stopped container
bind-mount
so layers survive
────────────────────────────────────────
File: internal/stack/stack.go
Change: Dropped the now-redundant releaseLiteLLMConfigOwnership
function and its call site in syncDefaults — --force-conflicts
Net effect: obol stack down/up cycles should be idempotent on
shared SSA fields, and dev-mode retries reuse cached image
layers instead of re-pulling from upstream every time.