fix: derive recipe build vmid#12
Open
ericwang401 wants to merge 7 commits into
Open
Conversation
cf now builds each VM under a slot-derived id (recipe base * 100 + slot index) so parallel builds don't collide. The post-processor passes that large id as CF_BUILT_VMID, but this script used it directly as the per-node template base and its `>= OFFSET` guard then aborted with exit 1 -- which, under `set -e` in vzdump-and-cleanup.sh, killed the post-processor before the sidecar was written, so the whole build was reported as "no artifacts created" despite a good .vma.zst. Recover the recipe base (RAW / 100 when >= OFFSET) before computing per-node VMIDs. A plain non-slot build still passes the base directly.
Header comment still described CF_BUILT_VMID as the per-node base and example (build_vmid 4001 -> node1=14001). Post-merge, CF_BUILT_VMID is the slot-derived id and BASE_VMID is recovered from it; update the comment to match.
The build VMID is slot-derived (recipe base * 100 + slot index) so parallel builds don't collide. cf-cluster-templates.sh then needed the recipe base back, and recovered it by dividing by 100 — gated on a >= OFFSET heuristic that coupled the slot multiplier (100) to an unrelated, user-tunable knob (CF_TEMPLATE_VMID_OFFSET). Raising the offset above a recipe's slot-derived id silently skipped the divide. The base is known at the source, so stop throwing it away: cf now exports CF_RECIPE_BASE_VMID (recipe.buildVmid) via buildRemoteEnv, which the shell-local post-processor and CF_UPLOAD_CMD inherit. The script reads it directly and falls back to CF_BUILT_VMID for plain non-slot builds (where the two are equal). Removes the /100 + OFFSET decode.
suggested_vmid was set to CF_BUILT_VMID, which is the slot-derived build id (base*100+slot) for parallel builds — so the published sidecar suggested an absurd clone target (e.g. 400100) instead of the recipe base. Use CF_RECIPE_BASE_VMID (falling back to CF_BUILT_VMID for plain builds), matching the base values the manifest fixtures expect. VM ops (vzdump/qm) keep using CF_BUILT_VMID — the actual built VM.
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
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.
This pull request updates how VMID (Virtual Machine ID) base values are handled and exported throughout the build and post-processing scripts, improving clarity and correctness for both parallel and plain builds. The changes ensure that both the slot-derived and recipe base VMIDs are correctly set and used, preventing errors in downstream scripts and making the build process more robust.
VMID Handling and Export Improvements:
The
CF_RECIPE_BASE_VMIDenvironment variable is now exported during the build process, allowing downstream scripts to directly access the recipe base VMID instead of having to reverse-engineer it from the slot-derived VMID. (src/build.ts,src/build/packer.ts) [1] [2] [3]The logic for determining the base VMID in
builds/_shared/post/vzdump-and-cleanup.shandscripts/cf-cluster-templates.shnow prefersCF_RECIPE_BASE_VMIDwhen available, falling back toCF_BUILT_VMIDfor plain builds. This ensures correct per-node template numbering and prevents VMID collisions. (builds/_shared/post/vzdump-and-cleanup.sh,scripts/cf-cluster-templates.sh) [1] [2] [3]The sidecar JSON metadata now uses the correct base VMID for the
suggested_vmidfield, improving accuracy for consumers of this metadata. (builds/_shared/post/vzdump-and-cleanup.sh)Documentation Updates:
CLAUDE.md,scripts/cf-cluster-templates.sh) [1] [2]Error Handling Improvements:
scripts/cf-cluster-templates.sh)