Repository navigation
[DO NOT MERGE] Validate disk_size_gb fix for 2025.12.0 -> 2026.0.0 migration disk-space failures - #740
Conversation
…ations Scratch validation only, not for merge. Trims test-migration.yaml's matrix to the 3 combos PEADM reported as disk-space failures (standard/large/extra-large -> 2026.0.0, which fail with "tar: ... No space left on device" extracting the PE 2026.0.0 tarball), and pins provision to the unreleased per-job-disk-size branch (puppetlabs/provision#303) with PROVISION_DISK_SIZE_GB set, to confirm the fix before #303 is tagged. provision_service's disk_size_gb support is already live in production. Revert the matrix trim, the .fixtures.yml ref, and the PROVISION_DISK_SIZE_GB env var once validated -- none of this should reach main. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
puppetlabs_spec_helper's ref option is for tags/commit SHAs only; branch names need the separate branch option, or FixtureHelpers#revision's git reset --hard <ref> fails since a bare branch name doesn't resolve against a fresh clone's refs/remotes/origin/* (unlike a tag, which is resolvable directly). All 3 jobs failed identically with "Invalid ref per-job-disk-size for spec/fixtures/modules/provision" before fetching the real provision_service disk-space fix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Code coverage overviewLanguages: Ruby, Puppet Ruby / code-coverage/rspec
Puppet / code-coverage/rspec-puppet
ℹ️ Calculations represent line coverage. Results may change as calculations are updated. Updated |
Scratch validation only, not for merge. The 2nd migration CI run failed at the identical tar file/byte-offset as before requesting disk_size_gb, suggesting GCP sized the disk but the guest OS never grew its root filesystem into the extra space. This workflow provisions one VM (no PE install) and inspects lsblk/df/growpart presence/guest-agent logs to confirm, without burning an hour-long full migration run per check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
….yaml Scratch validation only, not for merge. A brand-new workflow file isn't dispatchable until it exists on the default branch, so folds the single-VM disk-resize diagnostic into the already-registered test-migration.yaml as a second job, gated by a diagnose_only workflow_dispatch input so it can run without also re-triggering the 3-job migration matrix. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…gnostic Scratch validation only. First diagnostic run failed with an SSH auth error ~20s after provisioning returned -- the provisioner's startup script that sets up the litmus user likely hadn't finished yet, same class of race as other freshly-booted-VM SSH issues seen before. Adds a short wait/retry loop before the real inspection command instead of connecting immediately. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…cade Scratch validation only, not for merge. provision_service#448 (the disk_size_gb backend support) is only merged into its own PR branch so far, not main/release, so the task's default facade-release silently ignores disk_size_gb -- confirmed by a single-VM check showing the boot disk stayed at its unchanged 10G default. Points SERVICE_URL at the PR's own test-deploy facade (facade-per-job-disk-size), created automatically per docs/testing.md, instead of production. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Closing — validation complete and confirmed effective. Against this branch's test-deploy facade ( Tracked in CAT-2951. Real rollout depends on puppetlabs/provision_service#448 and puppetlabs/provision#303 getting reviewed, merged, and released — see that ticket for the rollout order. None of this branch's changes (trimmed matrix, 🤖 Generated with Claude Code |
provision_service now supports a per-job disk_size_gb override (provision#303, released as provision v3.2.0). Bump the .fixtures.yml pin and request 100G for standard/large/extra-large -> 2026.0.0 combos, which were confirmed failing with "No space left on device" while extracting the PE 2026.0.0 tarball on the default 10G boot disk. Scoped the same way as the existing PROVISION_MACHINE_TYPE override. Validated in #740. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Do not merge — scratch validation PR
Validates the fix for the disk-space failures PEADM reported on #718 (e.g. this job):
Confirmed root cause for standard/extra-large:
tar: ... Cannot open/mkdir: No space left on devicewhile extracting the PE 2026.0.0 tarball duringpeadm::pe_install, on the default-sized boot disk provision_service creates (the source image's own default disk size, never explicitly set).standardfails at the same point with the same short duration but its log didn't capture the detailed tar output in this attempt; worth double-checking this run's result for that one specifically.Changes (temporary only)
.github/workflows/test-migration.yaml: matrix trimmed to just the 3 combos above (was ~16 jobs), to validate without burning CI time/cost on the unrelated rest of the matrix. AddsPROVISION_DISK_SIZE_GB(set to100), scoped the same way as the existingPROVISION_MACHINE_TYPEoverride..fixtures.yml:provisionpinned to the unreleasedper-job-disk-sizebranch (puppetlabs/provision#303, not yet tagged) instead ofv3.1.0, since that's wheredisk_size_gbsupport lives client-side.provision_servicechanges needed here — puppetlabs/provision_service#448 (the service-sidedisk_size_gbsupport) is already deployed to production.Next steps
Once CI confirms the 3 jobs pass, close this PR without merging, then proceed with the real rollout: merge provision#303, cut a new
provisiontag, and bump PEADM's real.fixtures.ymlpin in #718 (not this branch).🤖 Generated with Claude Code