Add bootc job

[amirfefer]

This pull request includes:

• adequate testing for the new functionality or fixed issue
• adequate documentation informing people about the change such as
  • submit a PR for the READMEs listed here
  • submit a PR for the osbuild.org website repository if this PR changed any behavior not covered by the automatically updated READMEs

Draft PR: Adding Disk Image Creation Job Using bootc-image-builder

This draft PR is primarily created to explore the composer architecture and understand its workflow better.

Summary

This PR introduces a new job to create disk images from a bootable container using bootc-image-builder (bib) as a black-box tool. The generated image artifact and manifest are stored in the output directory: /var/cache/osbuild-composer/output. With this addition, the composer serves as a job orchestrator rather than handling the image-building logic directly.

Key Changes

1. Modified ImageRequest:

   • Added a new field image_ref to reference the bootable container.
   • Introduced two corresponding imageTypes.
   • Note: This PR assumes that only one ImageRequest will be provided as payload. Further refactoring of ImageRequest may be needed, as some fields (e.g., distribution) are not applicable for a bootc build and should not be mandatory.

2. Image Types:

   • The new image types are designed to work specifically with bootable containers, leveraging bootc-image-builder.

Testing

• The changes were tested locally by building a disk image from an RHEL bootable container.
• The process successfully output the disk.qcow2 file in 39 seconds.
• Additional outputs generated:

manifest - finished successfully
build:          9de450f801b7a0d3b158b4684bcbcdf0a48bd05bbc6d230afcc0c33b0f2e8a4f
ostree-deployment:      054e02d272dcd37b3d860b748934388a42f6a3175b64a4f54b9cf65de4042bda
image:          ff7f256da9e09eff5fbd99d87b950e0a771adf6ff6532baf6b76e2057ae4f2e7
qcow2:          335b4468fa169e73a9e699891f8dc806c65f3be64053dc6a9606f907946ee533
vmdk:           80bec78fa604f4e0a5ff26d7a855eb2e3fff80645ce9d07ac0762aaf234fcb81
ovf:            260fa8b317e4f573cb364809920a05a08d2b3d8e2c7a62db0bf8ce1d49e4698d
archive:        52e54d096a33b0ef280570c2e0b66ee01dde0e42b55b601eecceabb9db548242
Build complete!
Results saved in

Open Questions & Considerations

• Uploading Image Artifacts:
  • Given bib's limited support for upload targets, how should we handle artifact uploads? One idea is to leverage the native composer job for uploads.
• Pin bib version
• Builds Caching:
  • Should we consider implementing a caching mechanism for builds?
• Using konflux for Building:
  • Would konflux be a better choice for the build process instead of the current setup?

If you have any additional thoughts, suggestions, or concerns, please feel free to share them!

[croissanne]

Not a review, looks like you've made a lot of progress already. But keep in mind that osbuild needs to be invoked on the worker-executor if so configured. Look at internal/osbuild-executor. @mvo5 suggested to maybe just let bib generate the manifest, and then let osbuild do the rest. And then this job is essentially a manifest-like job.

[croissanne]

Is it feasible to just keep the image types the same name, and put something in the image-request? Like as soon as you specific bootc: {something...} in the IR with the image type being guest-image, composer will go ahead and make an bootc'd image for you for the requested type. ITs that aren't supported would just 400 ofc.

[amirfefer]

Thanks @croissanne,

It would be great to have bib handle just the manifest creation. This would also allow us to upload to multiple targets using the existing osbuild job. However, since bib is currently written as a script, this would require some refactoring. We could extract the relevant logic into callable functions or introduce a flag to output only a manifest.

[mvo5]

Thanks @croissanne,

It would be great to have bib handle just the manifest creation. This would also allow us to upload to multiple targets using the existing osbuild job. However, since bib is currently written as a script, this would require some refactoring. We could extract the relevant logic into callable functions or introduce a flag to output only a manifest.

I'm sure I'm missing something here but when I read bib I assume it means bootc-image-builder which is a go program in https://github.com/osbuild/bootc-image-builder and not a script. You can run:

$ sudo podman run     --rm     -it     --privileged     --pull=newer     --security-opt label=type:unconfined_t -v /var/lib/containers/storage:/var/lib/containers/storage     quay.io/centos-bootc/bootc-image-builder:latest     manifest --type qcow2     --local     quay.io/centos-bootc/centos-bootc:stream9
```
to get only the osbuild manifest out of bib. 

Now there are extracomplications because the osbuild-worker-executor runs in a restricted VM without network so we will have to find a way to get container over to the worker-executor. For normal images we ship the pre-populated content of the `osbuild-store` but we do not put containers into the osbuild store so there is a bit of brainstorming/programing needed. But given that we have a way to upload binaries (rpm currently) as part of the build request I guess we can just do something similar.

[amirfefer]

@mvo5, sorry for the confusion, You're right; bib is indeed a Go program. What I meant was that it's a CLI tool wrapped in a container. I wasn't aware that there's already a flag for outputting just the manifest. Thanks for pointing that out!

[github-actions]

This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled for 30+7 days with no activity.