Apologies for not responding earlier. It was a U.S. holiday and filtered. On Mon, 2023-11-27 at 14:56 +0100, Gerd Hoffmann wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > On Thu, Nov 23, 2023 at 10:52:47AM -0500, Neal Gompa wrote: > > On Thu, Nov 23, 2023 at 10:19 AM Gerd Hoffmann <kraxel@xxxxxxxxxx> > > wrote: > > > > > > Hi, > > > > > > We would like to add a new cloud image variant in Fedora 40, > > > which is > > > planned to be uefi only and will use UKIs. See the fedora change > > > page > > > for details: > > > > > > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_2 > > > > > > What does it take to get this done? > > > > > > First step will probably a pull request against > > > https://pagure.io/fedora-kickstarts.git adding a kickstart file. > > > > > > What is needed to add a new image to the image build process? > > > > > > What is needed to get > > > https://fedoraproject.org/cloud/download updated > > > to list the new image? > > > We can work with the web team to get them added to the download section. > > > Are there any other steps / changes needed? > > > > > > > We're actually in the process of moving to kiwi for this and have a > > new repo setup for that purpose: > > https://pagure.io/fedora-kiwi-descriptions > > > > David Duncan filed a ticket for getting kiwi enabled in Koji a > > while > > back, which we're still waiting on: > > https://pagure.io/releng/issue/11726 > > Hmm, I can't find a fedora change proposal for this. I think there > should be one? I'll write a change proposal draft if you think it's necessary. It can't hurt and only helps to more clearly define the scope of what we are trying to achieve. Furthermore, we can add a bit of an faq on the "why not osbuild" story that keeps coming up over and over. > > Also: Why move to kiwi? I had the impression the longer-term plan > is to move to osbuild once it offers all features needed (which is > not yet the case). So switching (temporarely?) to kiwi looks like a > pointless disruption to me. > I find "pointless disruption" is a bit judgemental. We've been working on this for the better part of a year and this accusation feels to me that it's a kind of disqualification of our effort and for that reason, makes me feel that you are trying to put me on the defensive. It's not a friendly and I'd like us to work on the problems, not use language that is abusive to the people who are contributing their time and effort. We started down the path of osbuild and switched to kiwi to achieve our goals. >From Fedora Cloud's perspective, osbuild lacks a few components we want to take advantage of today that are in our PRD[1]. Here are a few of the things that we have identifies architecturally that led us in this direction: - osbuild expects code written for each distribution it can build, and hard-codes content and content locations - osbuild requires writing code to teach it about every distribution it runs on - osbuild does not provide a supported method to run arbitrary logic in an image build - osbuild does not provide a supported method to overlay arbitrary files into the image rootfs The first two problems mean that any blueprints we make are not reusable for downstream consumers nor derivatives who may want to use our image descriptions to build their own. From the perspective of encouraging people to remix our stuff, that's not ideal. For additional users not able to fully define everything in blueprints means that it's a nightmare for image reproducibility, because people need exactly the same osbuild versions to get the same output, which was something we avoided by using kiwi. The last two bulleted issues are why cloud chose to use kiwi to do our own customizations. Without them we find it difficult if not impossible to support work that downstream consumers need to customize for others and build their own custom images. We end up hearing from them that they need to use two tools to do it: osbuild for the first part and then use something like complex cloud-init scripts, or Amazon's ec2- imagebuilder or Hashicorp's packer for the customization. We'd like to maintain a significantly more consistent process. I am aware that this is on the roadmap for osbuild, but it's code complete in kiwi today and does not require us to wait. I don't see kiwi as a disruption so much as an opportunity to create a program that others can use to use to reproduce for multiple builds by using composable configuration. I see a lot of workloads move to the cloud, then some component requires repatriation, etc. We want that open source user build process to go with them. The integration with Kiwi is valuable in itself and it gives us some options that we would like today that we are working to implement that aren't currently prioritized for osbuild, like the WSL. Our focus is on eliminating imagefac[2] and we can get a lot closer to where we want to go with kiwi as a tool faster. It's why we wanted to get the integration with koji in place. > First step into that direction seems to be here: > > https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder > I recognize that as beneficial and includes changes that we need in the cloud images today. We also want to have a Fedora Workstation in the cloud images for ML/AI and vizualisation. This Image Builder support is a great step forward as a deliverable. We'll continue to identify the osbuild work as a high priority, but it won't stop us from asking to have support for kiwi in the koji builds so that we get the WSL out and various customizations to support the major clouds. Also, it's important to keep in mind that Fedora Workstation and Fedora Cloud are two different groups. We use different tools for building images today so their changes are typically independent of those we make. Currently, Fedora Workstation uses Lorax and Fedora Cloud uses ImageFactory[2] and Oz. We are working aggressively to eliminate our usage of ImageFactory because it is legacy code and not easily extended. We find that kiwi provides the most consistent experience with the least number of concerns over our deliverables. [1] https://fedoraproject.org/wiki/Cloud/Cloud_PRD [2] https://github.com/redhat-imaging/imagefactory -- _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-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/cloud@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
