fix(k3s): count-up/respec join legacy (pre-K3sNode) clusters (bug 2)#116
Merged
Conversation
Bug 2 from the 2026-07-07 recovery: converging an existing cluster created via the old inline path failed with "resolve refs: K3sNode dev-cp-0 not found" -- the Plan-based count-up pointed each new worker join at $ref(K3sNode/<cp>), but a legacy cluster has no K3sNode resource for its control planes, so the worker VM was created but never joined. setJoin now branches: if the surviving CP has a K3sNode resource (Plan/ K3sNode-built clusters) it keeps the $ref so the resolver serializes ordering; if not (legacy inline cluster), it resolves the join token + IP directly -- CP IP from the cluster-state agent endpoints, node-token via SSH (cat /var/lib/rancher/k3s/server/node-token) behind a testable readCPNodeToken seam -- and sets concrete joinFrom/joinURLFrom values, which applyK3sNode already accepts as bare strings. Both the count-up (addNodesViaPlan) and respec (respecNodesViaPlan) paths use it. Tests: setJoin uses a $ref when the CP has K3sNode state, and concrete values (via the faked token reader) when it does not; existing count-up/ respec tests updated to seed the CP K3sNode state they implicitly assume (they exercise the Plan/K3sNode path).
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
1 participant
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.
Fixes Bug 2 from the 2026-07-07 recovery: converging an existing cluster created via the old inline path failed with
resolve refs: K3sNode "dev-cp-0" not found— the Plan-based count-up pointed each new worker join at$ref(K3sNode/<cp>), but a legacy cluster has noK3sNoderesource for its CPs, so the worker VM was created but never joined.Fix
setJoinnow branches on whether the surviving CP has aK3sNoderesource:$ref, so the resolver still serializes install ordering.cat /var/lib/rancher/k3s/server/node-token) behind a testablereadCPNodeTokenseam — and set concretejoinFrom/joinURLFromvalues, whichapplyK3sNodealready accepts as bare strings.Both the count-up (
addNodesViaPlan) and respec (respecNodesViaPlan) paths use it.Tests
TestSetJoin_UsesRefWhenK3sNodeExists(CP has K3sNode state →$ref),TestSetJoin_ConcreteForLegacyCP(no K3sNode state → concrete values via the faked reader). Existing count-up/respec tests updated to seed the CPK3sNodestate they implicitly assume (they exercise the Plan/K3sNode path). Full suite +-race, lint/staticcheck/modernize clean,make buildgreen.With #115 (bug 1), both recovery bugs are now fixed — and this one means openctl could have finished the
dev-worker-0rejoin itself.