fix(stack): don't treat own cluster's ports as conflicts under --force#792
Open
bussyjd wants to merge 1 commit into
Open
fix(stack): don't treat own cluster's ports as conflicts under --force#792bussyjd wants to merge 1 commit into
bussyjd wants to merge 1 commit into
Conversation
Reported by a teammate during v0.14.0-rc0 field testing. https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v
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.
Problem
obol stack init --forceis meant to tear down and recreate the same obol-managed k3d cluster, but port conflict handling treated that cluster’s own published host ports as foreign conflicts.stripConflictingPorts/rewriteConflictingPortsonly used a blind TCP-bind availability check (hostPortAvailable). When the existing cluster’s load-balancer was still bound to the canonical mappings (e.g.80:80,443:443), those ports looked “in use,” so init rewrotek3d.yamlto ephemeral host ports (e.g.65002/65003). After recreate, the stack was stuck on non-canonical ports even though--forcewas reinstalling the same cluster.Fix
Thread
force boolthroughBackend.Initso the k3d path can apply an ownership exception:force, inspect the existing cluster’s load-balancer withdocker port k3d-<cluster>-serverlb.ownedset (k3dOwnedHostPorts).rewriteConflictingPorts, keep a mapping whenavailable(hostPort) || owned[hostPort].ensureK3dPortsAvailable(called fromUp()) still passesforce=false— see Limitations.Diagram
flowchart TD A["obol stack init --force"] --> B["Detect existing obol cluster published ports\n(docker port k3d-obol-stack-ID-serverlb)"] B --> C["For each default host:container mapping"] C --> D{"owned by existing cluster?"} D -->|yes| E["Keep canonical mapping\n(skip strip)"] D -->|no| F{"host port available?"} F -->|yes| G["Keep mapping"] F -->|no| H["Strip mapping\n(+ ephemeral fallback if needed)"] E --> I["Recreate cluster on canonical ports"] G --> I H --> IValidation
Actual output:
(
gofmt -lprinted nothing;go build ./...succeeded with no output.)Limitations
ensureK3dPortsAvailable(the re-check inUp()before a freshk3d cluster create) does not get the ownership exception. It doesn’t need it: that path only runs when the cluster is not currently running under that name, so there is nothing left to “own” those ports.k3d-<cluster>-serverlbDocker container’s published ports. If a future k3d config removes the load-balancer node (disableLoadbalancer: true), this signal degrades to “no exception” (safe fallback to the old strip-on-bind-failure behavior), not a wrong answer.https://claude.ai/code/session_01PnhCQLz7CHuDBUhWd5xF8v