Re: add cloud image

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Apologies for not responding earlier. It was a U.S. holiday and

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:
> > > 
> > >
> > > 
> > > What does it take to get this done?
> > > 
> > > First step will probably a pull request against
> > > adding a kickstart file.
> > > 
> > > What is needed to add a new image to the image build process?
> > > 
> > > What is needed to get
> > > updated
> > > to list the new image?
> > > 

We can work with the web team to get them added to the download

> > > 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:
> >
> > 
> > David Duncan filed a ticket for getting kiwi enabled in Koji a
> > while
> > back, which we're still waiting on:
> >
> 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

   - 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:

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. 

cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux