Add iso building scripts

[kwozyman]

The following should generate an installation iso with the container image already inside:

make image iso EMBED_IMAGE=quay.io/centos-bootc/centos-bootc:stream9 ORIGINAL_ISO=CentOS-Stream-9-latest-x86_64-boot.iso SSHKEY="my public ssh key"

[rhatdan]

Why is this only for training, it would also be good for other bootc containers.

I think we need to talk about whether we want this in addition to bootc-image-builder.

@cgwalters WDYT?

[lmilbaum]

Could you please check that this image is built/tested in CI?
Could you also add a README file for iso-builder?

[kwozyman]

From what I can tell, this image isn't built in CI

[Gregory-Pereira]

Ill add changes for the CI stuff. Typically I encourage users to add the related CI workflows when they introduce new images. However were having a little bit of a resources issue within the container org about access to github runners, and were in the process of migrating.

[Gregory-Pereira]

So upon closer inspection, it seems that there is no isolated container for the image-builder, it uses the make command to directly pass the arguments and make an iso-builder tailored to the parent provided image. Using your example, calling: make image iso EMBED_IMAGE=quay.io/centos-bootc/centos-bootc:stream9 ORIGINAL_ISO=CentOS-Stream-9-latest-x86_64-boot.iso SSHKEY="my public ssh key" will produce an image called quay.io/ai-lab/iso-builder:latest that is ready to build an iso from centos-bootc upon podman run ... -- we do not want this. There are some options for the refactor.

The simplest solution is to set the defaults with how we tag this image to indicate this existing paradigm. IE, if by our default parent image is quay.io/centos/centos:stream9, then by default we should tag this image quay.io/ai-lab/iso-builder/centos/centos:latest or something along those lines.

Ideally however, we would refactor the iso-builder to be a standalone container that you can pass arguments to, which I consider the best option. In a pattern similar to our other bootc images it would be able to pull in the parent image, and be able to run the iso-builder.sh script from there. This would require stuffing podman into this image, which would increase the size, and honestly im not sure thats something we want to do.

[Gregory-Pereira]

This does not work, ubi does not ship with DNF, and will fail in the container build. Either update package deps to work for this option or remove the example

[lmilbaum]

Hmm.... ubi does not ship with dnf?

[Gregory-Pereira]

Sorry my mistake, package lorax not available on ubi9:

 make image FROM=registry.access.redhat.com/ubi9/ubi:latest
"podman" build \
		--file Containerfile \
		--tag "quay.io/ai-lab/iso-builder:latest" \
		--from=registry.access.redhat.com/ubi9/ubi:latest \
		 \
		 \

STEP 1/5: FROM registry.access.redhat.com/ubi9/ubi:latest
STEP 2/5: RUN dnf install -y skopeo buildah lorax
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

Red Hat Universal Base Image 9 (RPMs) - BaseOS  831 kB/s | 421 kB     00:00
Red Hat Universal Base Image 9 (RPMs) - AppStre 3.0 MB/s | 1.7 MB     00:00
Red Hat Universal Base Image 9 (RPMs) - CodeRea 379 kB/s | 114 kB     00:00
No match for argument: lorax
Error: Unable to find a match: lorax
Error: building at STEP "RUN dnf install -y skopeo buildah lorax": while running runtime: exit status 1

make: *** [image] Error 1

[cgwalters]

Yeah I would probably argue that mkksiso should be clearly split from lorax and put in the bucket of "things we generally support in the product". Whereas "lorax" is an implementation detail of building the anaconda ISO that can and probably will change in the future.

[Gregory-Pereira]

currently encountering what I presume to be a flake:

STEP 2/5: RUN dnf install -y skopeo buildah lorax
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered with an entitlement server. You can use subscription-manager to register.

CentOS Stream 9 - BaseOS                        355 kB/s | 8.1 MB     00:23    
CentOS Stream 9 - AppStream                     [158](https://github.com/containers/ai-lab-recipes/actions/runs/8972993169/job/24642196356?pr=416#step:7:159)  B/s | 4.4 kB     00:28    
Errors during downloading metadata for repository 'appstream':
  - Downloading successful, but checksum doesn't match. Calculated: 1ca04bb759f69eb64e351e75b26cc8a8b7be1659fe331c03ffbf96b8c7d8505d489cb7ca81d3528d22d2050c7823ed8e7b8aad39799ebb3cfee488727a046177(sha512)  Expected: 8eab4065ef6804df88ca58b7f67806151e9e7141316434657dc7c9b4ed04079bfc62259570fd5e09458195ab90fa93e80abee9248e0b5faf2ee1a189498a8772(sha512) 
Error: Failed to download metadata for repo 'appstream': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Error: error building at STEP "RUN dnf install -y skopeo buildah lorax": error while running runtime: exit status 1
make: *** [Makefile:19: image] Error 125
Error: Process completed with exit code 2.

[Gregory-Pereira]

Tests pass. I will now hand this back to @kwozyman for refactor. Please keep tests in alignment with whatever changes you want to make.

[Gregory-Pereira]

bump @kwozyman. If you really dont want to refactor we could still potentially proceed with just this if we get approval from @rhatdan and then iterate as we go. Thoughts?

[rhatdan]

I have not heard an argument on why we would want this and not to just use bootc-image-builder?

[Gregory-Pereira]

None from my perspective, I was just trying to prevent work from getting stale.

[lmilbaum]

Can you please rebase?

[kwozyman]

Sorry folks, I was on Summit + PTO

@rhatdan it was your suggestion to include this. Do we still want it in?
I think the advantages over image builder are speed and not needing a privileged container. The disadvantages would be lack of customization (I'm not 100% sure what image builder offers).

[rhatdan]

@cgwalters WDYT?

[cgwalters]

You can drop --no-signature-verification btw.

[cgwalters]

I totally get where this is coming from - it is putting together some things we have in a relatively straightforward way. However, it does also overlap with the anaconda-iso type from bootc-image-builder, and notably osbuild/bootc-image-builder#438 which will allow more flexible configuration.

So...I would hope we can get bib into a place where it handles these use cases more nicely, but at the same time I certainly wouldn't block anyone bypassing it where it's blocking things either.

[Gregory-Pereira]

No movement or resolution here. Converting to draft.