Skip to content

Add optional per-job disk_size_gb to provision_service task - #303

Open
LukasAud wants to merge 1 commit into
mainfrom
per-job-disk-size
Open

LukasAud wants to merge 1 commit into
mainfrom
per-job-disk-size

Conversation

@LukasAud

Copy link
Copy Markdown
Contributor

Summary

Adds an optional disk_size_gb to the provision::provision_service task so a job can request a specific boot disk size, instead of every consumer getting the service's single default (the source image's own size).

  • New task parameter disk_size_gb (Optional[Integer[1]]), with a PROVISION_DISK_SIZE_GB environment variable fallback. The parameter wins, matching machine_type. A blank value counts as unset.
  • It is sent as disk_size_gb on each entry in VMs, and omitted when unset, so the request body is byte-for-byte unchanged for existing callers.
  • Works for String, Array and Hash platform values.

Why

Following the machine_type fix (#301), the PE 2026.0.0 jobs in puppetlabs-peadm are now running out of disk space on the default-sized boot disk. Raising the default would raise cost for every consumer of the service, so we want to size only the jobs that need it. Same approach as machine_type.

Depends on provision_service, and merge order matters

This only changes what the task sends. puppetlabs/provision_service#448 must be deployed to production first: the service reads only cloud, images, region, zone and machine_type per VM today, so an older service silently ignores disk_size_gb and the job still gets the default disk size with no error.

Rollout: deploy provision_service#448 (merge to main, check the puppetlabs-motd nightly against it, then push main to release, per docs/production.md) -> merge this and cut a new provision tag -> bump the provision ref in the consuming repo's .fixtures.yml -> set PROVISION_DISK_SIZE_GB only on the jobs that need it.

Testing

  • New specs mirroring the existing machine_type coverage: disk_size_gb omitted by default and when blank, added for String/Array/Hash platforms, sent in the request body as an Integer, PROVISION_DISK_SIZE_GB fallback, parameter-over-environment precedence, blank values ignored, and passthrough from .run. The existing machine_type-only specs (.run, env-isolation around block) are extended rather than duplicated.
  • Ran with rspec -Ilib -Ispec (bundler can't resolve this machine's installed gem set; needed to install webmock locally first) — 37 examples, 0 failures.
  • RuboCop (pinned 1.50.2 where resolvable locally) reports no offenses on the changed files.

With Litmus, which cannot pass extra task parameters, set provision_disk_size_gb under params in provision.yaml (for litmus:provision_list) or PROVISION_DISK_SIZE_GB in the job's environment.

🤖 Generated with Claude Code

Mirrors the per-job machine_type parameter: a job can now also
request a specific boot disk size, sent as disk_size_gb on each VM
and omitted when unset so the request body is unchanged for existing
callers. Falls back to PROVISION_DISK_SIZE_GB; the parameter wins.

Depends on puppetlabs/provision_service's disk_size_gb support being
deployed first, same rollout order as machine_type.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@LukasAud
LukasAud requested a review from a team as a code owner October 28, 2026 15:01
@codecov-commenter

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.42%. Comparing base (d385e91) to head (134d7a9).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #303      +/-   ##
==========================================
+ Coverage   91.37%   91.42%   +0.04%     
==========================================
  Files           7        7              
  Lines         522      525       +3     
==========================================
+ Hits          477      480       +3     
  Misses         45       45              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants