Switch from hard coded disk size to variable?

[YannickRe]

Description

It looks like all image files have the os_disk_size_gb hard coded. Could this be updated to use a variable so that we could provide a different disk size? Almost all other parameters are configurable that way, just not this one.

Ubuntu 22.04:

runner-images/images/linux/ubuntu2204.pkr.hcl

Line 156 in 2ac4c5a

os_disk_size_gb = "86"

Ubuntu 20.04:

runner-images/images/linux/ubuntu2004.json

Line 55 in 2ac4c5a

"os_disk_size_gb": "86"

Windows 2022:

runner-images/images/win/windows2022.json

Line 44 in 2ac4c5a

"os_disk_size_gb": "256",

Windows 2019:

runner-images/images/win/windows2019.json

Line 44 in 2ac4c5a

"os_disk_size_gb": "256",

Thank you!

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• Windows Server 2019
• Windows Server 2022

Image version and build link

/

Is it regression?

No

Expected behavior

Make the os_disk_size_gb value configurable with a packer variable.

Actual behavior

os_disk_size_gb is hard coded to a specific value

Repro steps

/

[vpolikarpov-akvelon]

Hey @YannickRe. Current image size looks optimal taking into account what software we install there. If you still want to change it you can patch Packer template either manually or automatically in your workflow (e.g. using sed).

[YannickRe]

I know it's optimal for you, but we need more disk space for our additional stuff 😄. And yes, I can patch it with sed and some commandline magicary but why don't you parameterize it like you do with everything else?
It would not have an impact for you and your images but it would make our lives easier, and we would very much appreciate it 😄

[egg-r]

+1 for please update the os_disk_size_gb setting to be a variable with a default value. I'm using the templates for self-hosted Azure DevOps agents (VMSS) and currently running into an issue where expanding the OS drive may be the only work around for an issue I'm facing. The runner image release I'm currently using has about 31GB of free disk space, and running into build issues as at least 40GB free disk space is needed for a ML workload w/ GPU support.

[ryan-adler]

We are in a very similar situation. I don't see why this couldn't be made easier to change and less dependent on the existing files. If we try to edit these things inline, we run the risk of that breaking when the structure of the files in this project changes. Variable for disk space seems logical here. In the case where a VM is used for a single build, a fixed disk size is usually ok, but with VMs that have longer lifetimes (and therefore more possible builds over time), this is not ideal.