Hi, As I wrote earlier, I could not afford to wait any longer that things gets unbroken on the image finder and in our image production chain, and decided to implement things my way.
The main idea behind what I've done is that I want to empower our users to build images, rather than build the images for them. Of course, both is possible, but that's a very different idea from what's currently being done in our Salsa CI. The result is that the openstack-debian-images source package now produces 3 binaries: - openstack-debian-images - openstack-debian-images-build-farm - openstack-debian-images-updater The first one is my good-old script, though it now does what Steve implemented in Perl: all useful artifacts are signed, a packages.list is produced next to the built images, and a source.tar.gz contains the source packages used to build the images. It also now contains the logic to produce Octavia images built-in (rather than a hook script as done previously). The 2nd one contains the necessary scripts to build a server with all the OpenStack Debian images that one wishes. The result is what you can see over here: https://openstack-images.debian.net/ I've setup my server to produce images for Stretch, Buster, Bullseye and Sid. This is done through a simple configuration file. Also, Octavia images are produced, for Buster and OpenStack Train & Ussuri (using the unofficial backport repositories), plus the Octavia image for Bullseye and Bullseye + OpenStack Wallaby. Every day, the "daily-openstack-debian-image" checks what's in the "packages.list" of each image, against what's in the Debian repositories. If the image needs an update, it's built, and then the old image is moved in an archive folder. I've setup the same kind of image build service for my own company, just changing the sources.list of the images so they point to our own mirrors. This was also something I wanted to do for a long time. The package of the 3, contains a small scripts that downloads the images from a server setup with openstack-debian-images-build-farm, and uploads the images automatically to a OpenStack cloud. Many images and OpenStack clouds can be listed, with different credentials, and the script will take care of uploading updates of multiple images to multiple clouds. I've uploaded all of this to Debian Experimental, and it's waiting in the NEW queue. I'd be ok with having all of this reimplemented using FAI, and the Python wrapper on top. Though I don't want to be the person doing it, for various reasons already explained earlier in this list. Explicitly, I do not want to deal with the limitations self-imposed by the team which I find very stupid, like the limit in the artifact size. I also do not wish to waste time re-implementing stable URLs, clean-up dailies, etc., because it is my point of view that it is up to the persons who decided to rewrite everything to do the job. I also don't feel like spending too much time trying to understand the current Python code base that will not allow having independent simple to use scripts like I have designed. All this being said, I'm ok (and would very much welcome) if someone takes over the work and do it "the team's way", even though I have very little hope at this time, that this will ever be done. There's a lot of room from improvement in what I wrote, which I feel is very hackish. For example, openstack-debian-images-updater would need to check for the artifact's GPG signatures. Though it's doing the job, and it's good enough for what I need. I just hope it will help others. Cheers, Thomas Goirand (zigo)
