Hi everyone,
on one of the first meetings regarding the new WebUI for the installer, I was also mentioning that we would love to switch the building tool for the Live ISO from livemedia-creator to Image Builder. This is our joint effort to modernize the image building stack in Fedora to something actively maintained and better tested.
livemedia-creator
I think that we are ready to propose the switch for Fedora 39, so I went ahead and created a proposal: https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
The goal of this change is to be invisible for end users - basically, they shouldn't notice that anything changed in the media. In other words, our goal is that medias built by livemedia-creator and Image Builder are the same.
One important highlight: From Image Builder's point of view, there's only small difference (one package) between building an installer with the old UI and with the new UI. Thus, I believe that these changes are basically independent. However, both teams collaborate closely, so if any issues appear, we are ready to investigate together.
Anyway, I don't want to repeat what's written in the proposal. I'm happy to answer all questions you might have. :)
Do we have layered blueprints yet (similar to layered kickstarts and kiwi descriptions)?
In the first iteration, I think we can go "blueprint-less". Basically, you tell Image Builder to build a live workstation ISO with an empty blueprint, and it just knows which packages to install.
Blueprints currently disallow removing packages from the base package set, so this unfortunately means that it's not possible to build a smaller image. However, the advantage is that end users are less likely to break their images by "removing too much". Also, it's dead simple to reproduce the official image build anywhere else.
I'm aware that this approach doesn't scale well to other spins that build live images. That's why we limit the scope of the first change to just one artifact. After the first iteration, that's the next step we want to take: Take a look at what other spins need in order to customize their image and then come up with the best strategy how to deal with the requirements.
I'll put this on the agenda for our 4 July meeting. It would be great if you could attend, @obudai.
I will be there. :)
July 4 is the US Independence Day. The likelihood of me coming to that meeting is pretty low. :statue_of_liberty:
Five of the nine Working Group members are in the US, so I would recommend skipping next week. ;)
OK, let's do it on 11 July instead.
Reminder: this topic will be discussed today at 1000 Eastern.
I have a conflict, so I won't be there today, but here's my comment on this topic:
Rather than replacing our existing lmc-based build with this, can't we add an Image Builder-based build and ship it somewhere out of the way so we can evaluate it? On the mailing list, there have been a number of issues brought up about the current pipeline for osbuild-based images, and I'm not comfortable with us replacing things just yet until those issues are resolved. At the same time, I don't want to block their development of this image and I want us to be able to fairly evaluate the experience, which can't be done without the image actually being made for us to see. Thus the idea of continuing lmc-based Workstation images for now as the blocking deliverable and offering the osbuild-based Workstation image as an alternative image until we're in a place to enable successfully replacing it for Workstation and all Spins.
Hi, as discussed today here's a recent build to an x86_64 ISO: https://fedorapeople.org/groups/anaconda/webui_preview_image/x86_64/fedora-preview-live-installer-2023-06-29.iso
@ngompa I'd like to consider that our contingency plan, if the current image(s) being built are not up to par we'd like to be building as a side compose (if that is the correct term) for the coming cycle to iron out any issues.
Some things that popped up on the mailinglist that we're working on, I'll provide new ISOs as they get fixed (where relevant):
A big change would be how to attack the edition/spin definitions in blueprints. We are discussing multiple ways of doing so ranging from blueprint inheritance, defining a Fedora base that can have any edition defined on top of it, changing how we do definitions internally, and some others. We will present this in a change proposal for F40, separately from the current change proposal where we will expand to build the 'biggest' editions (workstation, kde, etc).
I am wondering how the technical acceptance process for the built artifacts works and where we will communicate any changes/issues with the current builds. I am also interested in maybe getting together with @adamwill to see how we can integrate/what we need to do for OpenQA.
We discussed this on 11 July. Some notes from that conversation:
Current status:
Outstanding questions
My general impression is that we're still waiting to see if all the pieces come together in time for F40.
There is an image that has been built. This will be tested. If it has technical issues that can't be solved in time for F39, then they will go with Neals suggestion as a fallback plan.
FESCo has already requested that we go with the fallback plan.
Looks like we can close this.
Metadata Update from @aday: - Issue close_status updated to: Can't fix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.