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
