-
Epic
-
Resolution: Done
-
Major
-
None
-
Consolidate information uploaded to Koji for image builds
-
False
-
None
-
False
-
To Do
-
RHELBU-1740 - New Interactive Installer
-
0% To Do, 0% In Progress, 100% Done
Goal: Consolidate Koji integration implementation to attach important information to the Koji build, instead of the Koji task.
Key results: osbuild-composer is attaching information which should not be garbage-collected to the Koji Build.
Acceptance criteria:
- Image manifest is uploaded to the Koji Build, instead of the Koji Task.
- Task ID is attached in the “extra” property of the metadata imported by Content Generator to Koji.
- The information needed to locate the image in the appropriate cloud environment (Target-specific Upload Status) is attached to the Koji Build (as a separate file or in the “extra” property of the metadata.
Dependency: None
Customer: Internal (SP), Fedora rel-eng
Contacts: tmlcoch@redhat.com (SP)
Notes:
An example of the image build in Brew:
- Task - https://koji.fedoraproject.org/koji/taskinfo?taskID=101288407
- Build - https://koji.fedoraproject.org/koji/buildinfo?buildID=2202564
As it turns out, osbuild-composer is uploading all of the information related to the image build to the Koji Task, including the compose-status and manifest used to build the image. Unfortunately, files attached to the Koji Task get garbage-collected at some point. As a result, some information that should be preserved with the image build gets lost.
This is potentially very problematic in the case of the lost manifest. One of the big features of Image Builder and osbuild manifests is the reproducibility of image builds. However in order to easily rebuild an image in exactly the same way again, one should use the original manifest used to build the image. This is not possible when the manifest is garbage-collected after some time.
With the addition of cloud uploads support for Koji composes, there are other types of information that we should be keeping persistently with the image build itself. Specifically the information to identify the image in the target cloud environment, which is now part of the `compose-status.json` uploaded to the Koji Task.
Relevant Koji documentation is:
- relates to
-
COMPOSER-2008 Expose the image boot mode in the Koji build extra metadata
- Closed
- links to