Add per-cpu and per-task boot disk IOPS and throughput options

[eastagiletracker]

This PR proposes adding per-CPU and per-task versions of the boot_disk_iops and boot_disk_throughput options (Fixes #8). We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/359. You can sign in with your GitHub ID to claim ownership of the project.

What changed and why

Issue #8 notes that boot_disk_iops and boot_disk_throughput are absolute values, while many other parameters also have per-CPU and per-task forms. docs/config.rst documented that limitation directly: "this is an absolute value and is not scaled by the number of vCPUs or tasks". The practical effect is that one configuration cannot provision proportional disk performance across instance types of different sizes — a value that suits a 2-vCPU instance starves a 32-vCPU one, and a value sized for the large instance overprovisions every small one.

Reproduced on main at 482c093:

$ python -c "from cloud_tasks.common.config import RunConfig; RunConfig(boot_disk_iops_per_cpu=2000)"
pydantic_core._pydantic_core.ValidationError: 1 validation error for RunConfig
boot_disk_iops_per_cpu
  Extra inputs are not permitted [type=extra_forbidden, input_value=2000, input_type=int]

$ cloud_tasks run --help | grep -c boot-disk-iops-per-cpu
0

This adds boot_disk_iops_per_cpu, boot_disk_iops_per_task, boot_disk_throughput_per_cpu, and boot_disk_throughput_per_task to RunConfig, with the matching command line options, following the shape of the existing boot_disk_per_cpu and boot_disk_per_task size options. The arithmetic lives in a new InstanceManager._get_boot_disk_provisioned_amount() alongside _get_boot_disk_size() and mirrors it: the amount is the maximum of the absolute value, the per-vCPU value times the number of vCPUs, and the per-task value times vcpu // cpus_per_task, so the absolute option now acts as a floor. The result is rounded up, so a disk is never provisioned below what was asked for. GCPComputeInstanceManager.get_available_instance_types() resolves both amounts per instance type at the point where it already computes the boot disk size, so the scaled values flow through instance pricing, optimal instance type selection, and start_instance() with no further changes.

On backward compatibility: with no per-vCPU or per-task option set, each value collapses to max(absolute_or_default, 0, 0), which is exactly the previous result. No existing option changes meaning and nothing is removed — the existing assertions that an unconstrained instance reports 3120 IOPS and 170 MB/s still hold unchanged.

Verification, on Python 3.12:

$ python -m pytest -q       # before: 475 passed, 1 skipped
$ python -m pytest -q       # after:  486 passed, 1 skipped
$ ruff check src tests      # All checks passed!  (before and after)
$ mypy src                  # Success: no issues found in 22 source files  (before and after)

The 11 added tests cover the new arithmetic (provider defaults, absolute only, per-CPU, per-task, the maximum of several at once, rounding up, and the throughput option names), the end-to-end result from get_available_instance_types() for both fixture instance types, and config validation including rejection of negative values. To confirm they really do pin the new behavior, reverting only src/cloud_tasks/instance_manager/gcp.py to its current state on main and re-running turns the two scaling tests red (assert 3120 == 4000) while the absolute-value and config tests stay green.

Documentation is updated in docs/config.rst, docs/cli.rst, and docs/provider_gcp.rst.

One merge note: #51 is open and also touches common/config.py, cli.py, and instance_manager/orchestrator.py, for max_memory_allowed_per_task. The edits here are in different parts of those files, but whichever lands second may want a small rebase.

How this was managed

We imported this repository's issues and pull requests into a live agile board and tracked this work on it: issue #8 as a story on the project board, which holds 45 stories imported from here.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

---

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com

[coderabbitai]

Important

Review available on request

• 🔍 Trigger review

Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment @coderabbitai review to review the latest changes. For a full review, comment @coderabbitai full review.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 25a2273b-fab2-4e53-9305-8b476d8ac777

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}