New openstack-debian-images 1.61 in NEW
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)
Reply to: