On Mon, Jun 26, 2023 at 4:14 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > > On Mon, 2023-06-26 at 15:33 +0100, Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder > > > > This document represents a proposed Change. As part of the Changes > > process, proposals are publicly announced in order to receive > > community feedback. This proposal will only be implemented if approved > > by the Fedora Engineering Steering Committee. > > > > > > > > == Summary == > > Image Builder is a set of modern tools for building operating system > > images. Its goal is to make the builds reliable and reproducible. > > Moreover, it's designed to give the end users a simple workflow to > > build their own custom images. The aim of this change is to switch the > > build tool for Fedora Workstation live ISO from livemedia-creator to > > Image Builder. > > > > == Owner == > > * Name: [[User:obudai|Ondřej Budai]] > > * Email: obudai@xxxxxxxxxx > > * Name: [[User:Supakeen|Simon de Vlieger]] > > * Email: supakeen@xxxxxxxxxx > > * Name: [[User:jkonecny|Jiří Konečný]] > > * Email: jkonecny@xxxxxxxxxx > > > > > > > > == Detailed Description == > > Image builder is currently getting support for building > > [https://github.com/osbuild/osbuild-composer/pull/3440 live ISOs]. > > Once the PR implementing the new image type is merged, > > [https://pagure.io/pungi-fedora/blob/8b2c85799cce5c096484cdebe1dbe521eaf7fe92/f/fedora.conf#_530 > > the pungi-fedora configuration] needs to be updated. This change will > > ensure that pungi creates an osbuildImage task in koji instead of the > > currently used livemedia one. > > > > Pungi and Koji already support Image Builder, so no additional work is > > required there (refer to the > > [https://docs.pagure.org/pungi/configuration.html#osbuild-composer-for-building-images > > pungi] and [https://github.com/osbuild/koji-osbuild/ koji] > > documentation). The only missing part in terms of infrastructure is > > provisioning ppc64le worker machines for Image Builder, see the > > relevant [https://pagure.io/fedora-infrastructure/issue/11243 > > fedora-infra ticket]. > > > > Note that Image Builder is already used for > > [https://fedoraproject.org/wiki/Changes/IoTArtifactsWithOSBuild > > building ISOs and raw disks of Fedora IoT]. Therefore, this proposal > > does not introduce a new tool to the Fedora build pipeline. > > > > == Feedback == > > > > Currently, Image Builder does not populate the DNF database correctly, > > leading to all RPMs installed on the target system being marked as > > user-installed. This is [https://github.com/osbuild/osbuild/issues/455 > > a known issue] that the team is planning to address as soon as the > > initial support for live ISOs is merged. > > > > > > == Benefit to Fedora == > > The maintainer team of Image Builder believes that the project > > undergoes more comprehensive testing compared to > > lorax/livemedia-creator. Thus, by switching to Image Builder, Fedora > > should experience fewer issues with the image building pipeline. > > > > Another advantage is the project's emphasis on making Image Builder > > more user-friendly. End users can easily build their own customized > > version of the live ISO using a simple > > [https://www.osbuild.org/guides/image-builder-on-premises/blueprint-reference.html > > TOML blueprint file] and a > > [https://www.osbuild.org/guides/image-builder-on-premises/building-an-image-from-cli.html > > CLI interface]. This approach, utilizing well-known file formats, is a > > positive step compared to livemedia-creator's kickstart files. More > > information about building customized images can found on > > [https://major.io/p/build-custom-centos-stream-cloud-image/ Major > > Hayden's blog] or in > > [https://www.youtube.com/watch?v=PsQySAEOeFs&t=17001s a conference > > talk] given by Ondřej Budai, one of the proposal owners. Moreover, > > Image Builder provides [https://github.com/osbuild/cockpit-composer/ a > > graphical interface] for visually defining blueprints, further > > simplifying the workflow. > > > > We believe that Image Builder can also be beneficial to the > > [https://fedoraproject.org/wiki/Respins-SIG Respins SIG] as it nicely > > aligns with their objective of providing a simple method for building > > up-to-date, customizable images. > > > > == Scope == > > * Proposal owners: > > Finishing implementing support for the live ISO upstream and > > collaborate with release engineering to switch the pungi config to use > > Image Builder. > > > > * Other developers: > > Our focus for this change is specifically on Fedora Workstation. > > Nevertheless, we are open to collaborating with all spins/SIG to > > transition their build pipelines to Image Builder. However, for the > > initial switch, we aim to minimize the impact by focusing on a single > > artifact. We anticipate that more artifacts will be transitioned in > > subsequent releases of Fedora Linux. > > > > * Release engineering: [https://pagure.io/releng/issue/11500 #11500] > > Provide ppc64le machines to Image Builder. Switch the pungi config to > > use Image Builder. > > > > * Policies and guidelines: N/A (not needed for this Change) > > > > * Trademark approval: N/A (not needed for this Change) > > > > > > * Alignment with Community Initiatives: > > > > > > == Upgrade/compatibility impact == > > There shouldn't be any. The goal of this proposal is to build the same > > images as livemedia-creator does, just using a different tooling. > > > > > > == How To Test == > > Once the pungi config is changed, grab the ISO built by Image Builder > > and test if there are any unexpected changes. > > > > > > == User Experience == > > No change is expected. > > > > == Dependencies == > > The Workstation SIG and the installer team are working on a change to > > use the new installer web UI for the Workstation live ISO. We are > > fully aware of this change and have the capability to build ISOs with > > and without the new UI. As a result, these changes should be > > independent of each other. Furthermore, the installer and Image > > Builder teams are closely collaborating, ensuring that any issues that > > may arise can be addressed with high priority. > > > > == Contingency Plan == > > > > * Contingency mechanism: (What to do? Who will do it?) Release > > engineering to revert the change in pungi, so that the old tooling is > > used instead. > > > > * Contingency deadline: Final freeze (the change is trivially revertible) > > > > * Blocks release? No > > > > > > == Documentation == > > N/A > > > > == Release Notes == > > Fedora Workstations ISOs are now built using Image Builder instead of > > the legacy tooling used before. > > So, I don't want to throw any stop energy at this, but I have some > nitpicks. > > In terms of testing: we already test the existing toolchain pretty > effectively in practice. openQA builds Workstation and KDE live images > with every relevant critical path update. If an update breaks live > image creation, we find out about it right away, and the update is > gated. > > In terms of file formats: is toml really that much better known or > better than kickstart, for an audience of Fedora devs, for the purpose > of building a live image? Especially now we (finally) got the livesys > stuff out of the kickstarts and they're mostly pretty simple? As a > specific nitpick, the documentation on the Image Builder format makes > it clear that it supports comps groups, but it's less clear if it > supports comps *environment* groups. It really needs to do so to > maintain parity with livemedia-creator; we don't want to have to define > all the environment groups twice (once in comps, once in imagebuilder > TOML files). If it does support this, it should be made clear in the > docs. > > I notice the Change doesn't say much about debugging failed builds. > This is very important. Failed livemedia-creator tasks are quite easy > to debug. livemedia-creator as run in Koji by Pungi is very good at > providing sufficient logs to determine what the heck went wrong if an > image build fails. Other tools - notably ImageFactory - are notoriously > much worse at this. Where does Image Builder fall? > > As I said, I'm not saying we shouldn't do this. But I do think that if > it doesn't provide any really compelling benefits over livemedia- > creator, we should set a high bar for it also not having any > significant *drawbacks* compared with livemedia-creator. Additionally, do we have support for the layering/composition model for configuration snippets for blueprints like we do for kickstarts or kiwi descriptions? Without that, it's going to be hard to structure this in a way where we have reuse and separation of maintained configuration. Being unable to DRY the blueprints would be a big regression and quite painful for long-term maintenance of the image definitions. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
