Re: Bump Vagrant image size
Follow up on:
https://salsa.debian.org/cloud-team/debian-vagrant-images/-/merge_requests/11#note_285930
Emmanuel Kasper:
I think I would need at that point more context about your setup so that we direct you to the best Debian cloud image for your needs:
* you said you use the boxes to build android packages. Are you using a single box to build all your packages ? Is that part of a CI pipeline ? Which security issue and performance (metrics) have you noticed when using a large shared directory ?
This is used to build Android apps (APKs). We use a standard box to build any
app. It is provisioned and snapshotted. It is reset between each APK build so
each APK build starts from a clean VM. We don't use any shared directories at
all in the build process. The build job gets what it needs from the network.
The provisioned box is currently about 15GB. Many app builds will end up using
a lot more than 5GB in the process. Things like browsers, VLC, etc. will
sometimes use more than 100GB of disk space in the build process.
* also the generic image (https://cloud.debian.org/cdimage/cloud/bullseye/20210814-734/debian-11-generic-amd64-20210814-734.json) distributed in https://cloud.debian.org/images/cloud/ is built as such that if you change from the hypervisor side the disk image size, the root fs will automatically grow For this you would need an hypervisor with cloud-init support, the heavyweight contender is OpenStack, you have also Proxmox VE or oVirt.
What do you think ? I would suggest to reach out the debian-cloud mailing with answers on this, on we'll try to guide you at best.
We use libvirt and VirtualBox with Vagrant, so I have no opinion on the other
kinds of boxes or images. With the libvirt Vagrant box, we already can resize
it as part of the setup procedure. That works fine. We have found no good way
to do that with the VirtualBox Vagrant boxes. That's what this issue is about.
We've maintained our own boxes purely because we need the disk space limit to
be a lot higher. Since the actual image grows with usage, we have seen no
downside to setting the box's initial disk size to 1TB.
We'd rather contribute to maintaining these official boxes, than maintain our
own fork. For example, we've developed methods to do strong verification of
boxes as part of our provisioning.
.hc
--
PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
Reply to: