Followup on Vagrant Boxes with debian cloud images
Le 13/02/2020 à 14:17, Emmanuel Kasper a écrit :
> Hi
>
> I had a look this week on how to add to Vagrant support to debian cloud
> images.
> The box users have been regularly complaining about a lack of up to
> dates box, and building and uploading for 2 hypervisors * 3
> distributions is a bit overkill to do at home on a ADSL connection.
So after a month of pushing things here or there I came to the
conclusion that it should be easier if I manage vagrant boxes
in a fork of debian-cloud-images
I noticed three things with makes creating vagrant boxes in the
debian-cloud-images repo difficult:
* first I stumbled in bin/debian-cloud-images in hard coded values. For
instance amd64 implies grub-cloud-amd64 as of
https://salsa.debian.org/cloud-team/debian-cloud-images/-/blob/master/src/debian_cloud_images/cli/build.py#L69
grub-cloud-amd64 is however not needed for Vagrant boxes, which do not
provide facility for a serial console, and Vagrant with the VirtualBox
provider does not even boot with our kernel when a serial console is
configured but a virtual serial port is missing (the default configuration)
* after the disk image creation, Vagrant needs a special packaging step,
before the box is booted in the hypervisor, but the python build script
only has such a converting step when uploading. Up to now I have been
running E2E tests on the created box before uploading. It is unclear how
this could fit in the current workflow.
* also a minor problem, the cloud images include a defined package set,
whereas I rely on package priorities to install what comes in a box.
The idea of having a common git repo is nice, but I think it is
better to have common practises ( building on salsa, pushing a
release build on cloud.debian.org ), rather than sharing a codebase I
would pollute with
if arch == 'amd64':
if vendor == 'vagrant':
return 'GRUB_PC'
else:
return 'GRUB_CLOUD_AMD64'
and waiting for merge requests to be rejected.
In the end it comes all about the destination of the disk image. With
Vagrant you're supposed to run the disk image locally as a portable dev
environment, so it differs a lot from the need of having a remote secure
minimal server.
So now that the initial fai work is done (I have working virtualbox and
libvirt vagrant images which build with the gitlab runners), my highest
priority will be to add the e2e testing suite I had with vagrant-boxes
and prepare a new upload so I can close
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930367
Emmanuel
--
You know an upstream is nice when they even accept m68k patches.
- John Paul Adrian Glaubitz, Debian OpenJDK maintainer
Reply to: