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?
Are there any other steps / changes needed?
thanks & take care, Gerd
On Thu, Nov 23, 2023 at 10:19 AM Gerd Hoffmann kraxel@redhat.com 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?
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
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@redhat.com 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?
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?
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.
First step into that direction seems to be here: https://fedoraproject.org/wiki/Changes/FedoraWorkstationImageBuilder
take care, Gerd
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@redhat.com 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%C2%A0adding 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%C2%A0updated 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
On Mon, Nov 27, 2023 at 02:56:46PM +0100, Gerd Hoffmann wrote:
On Thu, Nov 23, 2023 at 10:52:47AM -0500, Neal Gompa wrote:
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?
Ping. What is the plan? Seems there is no progress on the ticket linked above, and the deadlines for change proposals are coming closer.
I have experimental changes working for both kiwi descriptions and kickstart files. I can prepare a PR for the one or the other, but preferably not for both. Suggestions how to move forward?
take care, Gerd
On Tue, Dec 19, 2023 at 03:36:21PM +0100, Gerd Hoffmann wrote:
Ping. What is the plan? Seems there is no progress on the ticket linked above, and the deadlines for change proposals are coming closer.
I have experimental changes working for both kiwi descriptions and kickstart files. I can prepare a PR for the one or the other, but preferably not for both. Suggestions how to move forward?
Ping again.
https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages it is approved by FESCO, yet there seems to be no progress on the rel-eng and pungi tickets for weeks.
Anyone knows what is up there?
I'm wondering whenever I should better prepare a fallback plan and get fedora-kickstart.git updates ready ...
take care, Gerd
On Fri, Feb 16, 2024 at 9:12 AM Gerd Hoffmann kraxel@redhat.com wrote:
On Tue, Dec 19, 2023 at 03:36:21PM +0100, Gerd Hoffmann wrote:
Ping. What is the plan? Seems there is no progress on the ticket linked above, and the deadlines for change proposals are coming closer.
I have experimental changes working for both kiwi descriptions and kickstart files. I can prepare a PR for the one or the other, but preferably not for both. Suggestions how to move forward?
Ping again.
https://fedoraproject.org/wiki/Changes/KiwiBuiltCloudImages it is approved by FESCO, yet there seems to be no progress on the rel-eng and pungi tickets for weeks.
Anyone knows what is up there?
I'm wondering whenever I should better prepare a fallback plan and get fedora-kickstart.git updates ready ...
Release engineering is working on enabling the kiwi plugin and the pungi PR to allow image builds with kiwi has been made: https://pagure.io/pungi/pull-request/1720
We're hoping to get things in place in the next couple of weeks.
-
Duncan, David -
Gerd Hoffmann -
Neal Gompa