Renewing the Fedora bootc (now image mode) initiative

Project Discussion
,
1

Hello!

On behalf of the Fedora bootc initiative group, I would like to open a conversation around renewing the initiative, renamed the Image Mode Initiative [1] (since bootc is now officially a CNCF trademark as an upstream project[2]), with a goal of ending the initiative after the Fedora 45 release or when the work is complete, whichever is sooner.

Why

We from the current initiative believe that there is a great opportunity for Fedora to use the upstream bootc tooling system to generate OCI artifacts that deliver layered operating system images with an immutable (or atomic) Fedora core. Various elements from the Fedora ecosystem, from CoreOS to Fedora IoT, are moving toward offering releases as OCI artifacts. We have not yet reached production capacity for a bootc-based system in Fedora. The initiative enables a time-boxed, milestone-focused path to enabling this capability for all of Fedora.

A plan

The initiative would aim to complete major milestones to a clean development pipeline for Fedora 44 and final, supporting milestones to a production pipeline for Fedora 45 before dissolving after Fedora 45’s release. Milestones would include the following:

  • Official base images are formalized and delivered using a production pipeline with a team of contributors supporting them by Fedora 45.
  • All subprojects (Atomic, CoreOS, IoT, etc.) delivering artifacts based on official base images in beta by Fedora 44 and in production by Fedora 45.
  • Deliver a pipeline that can sustainably host these images by Fedora 44.

The initiative would also identify and break down barriers to completing this task as work for various subprojects.

The initiative would also enable work towards Konflux [3] as a CI/CD system for use with Fedora. As a new space, the community can use the initiative as a learning and testing ground for Konflux, ensuring Fedora can ask for features and patches that will help make the tool into something that addresses all needs.

Structure

This initiative is subject to oversight by the Fedora Council, and it must include people from relevant SIGs and subprojects to ensure full representation from across Fedora. Change requests will follow the standard Fedora change process, which are all subject to the Fedora Engineering Steering Committee (FESCo).

Note that this initiative will not own any code to ensure that, when the initiative is dissolved at the end of its time, the proper owning subproject or SIG would be identified and already owning these changes. The initiative is primarily in place to ensure there is a space to have relevant discussions across the project and with relevant stakeholders from upstream and downstream projects, propose and encourage solutions, and ensure accepted solutions are sustainable.

For myself, I am here representing both the upstream bootc community and Red Hat’s Open Source Program Office (OSPO) as a long-time open source contributor and maintainer for other projects and communities. I can offer to help shepherd this initiative as the Lead from an organizational perspective to the benefit of both bootc and Fedora along with all of our respective downstreams, including Universal Blue.

I would like to propose @jspaleta as the executive sponsor per our discussions.

Please feel free to add your feedback to this thread, and I will do my best to respond or get the right person to respond in my stead.

Laura Santamaria
Community Architect, Red Hat OSPO

cc @jasonbrooks

  1. Regarding names, we all know names are hard. Image mode is the best we’ve been able to come up with. I’ll directly quote someone else’s explanation here: “… it helps also making the separation between bootc the application/binary and the idea/workflow behind image mode” - cverna_:matrix.org, initiative meeting on 2025 Sep 23, timestamp 15:43:21 - Meetbot Logs ↩︎

  2. The onboarding issue in the CNCF, which means bootc is now a Linux Foundation trademark as noted in Trademark Policy - LF Projects, LLC. ↩︎

  3. Konflux is the CI/CD system of choice for this effort as work will be running in parallel on the system with both CentOS and RHEL. We can take advantage of the improvements from these other two projects while working in an open source environment. ↩︎

16 Likes
2

Hello @nimbinatus and welcome to Fedora Discussion!

This is great news!

Is this the main space where the community can participate? In what other areas would the initiative and SIGs need and be able to accept work from contributors outside of the official Fedora and Red Hat structures?

4 Likes
3

I really like the idea of this initiative for several reasons!

  1. This would simplify the relationship between different sub-projects
  2. It would focus limited resources on a single technology
  3. A single technology would be easier to talk about and explain to the world
  4. It would provide MUCH better alignment with RHEL
  5. It would help Fedora become a thought leader in this space

I also so a proposal by Clement to call this “Image Mode for Fedora” to align with “Image Mode for RHEL” and I really like that as well (as a product manager in the RHEL BU). I think we should ahve Fedora and RHEL align more on projects like this!

11 Likes
4

Thank you for working on this! It may also be sensible to rename the “Atomic Desktops” to “Image mode desktops” once this initiative is over, to further align naming?

1 Like
5

Great questions! I was so focused on the why that I forgot to add the how :sweat_smile:

We have the following spaces where general collaboration is happening:

As the initiative would bring together many different SIGs and subprojects and explicitly does not own code, the community can participate in a lot of different ways. If folks want to work on the initiative itself (blending together work and charting a course), then folks can collaborate in the spaces I named here. If folks want to get hands-on, this is a great opportunity to find a SIG (or start one!) that meets their area of interest :slight_smile: Some relevant SIGs I can think of that might be part of this initiative include

Of what does not exist today, I suspect something like an experimentation SIG (for rapid incremental improvement of new tech) or Konflux-specific SIG might also be of interest. There is the CI SIG, but I know there’s a ton of work there already. A separate SIG (or perhaps a working group within that SIG? I don’t know what the structure would be here in Fedora) might be a better option to allow for experimentation and getting Konflux to production parity within the community without jeopardizing production-focused activities.

3 Likes
6

Sounds good to me. I think there has been momentum and we should keep it going! Fedora CoreOS has been working towards being a layer on top of the bootc base images already.

I’m interested to know what this means in more concrete terms. What is “the initiative” exactly today? If “the initiative” dissolves after Fedora 45, what is going away as part of that?

4 Likes
7

Personally, I do think renaming them is a good idea, and I suspect this will be a long conversation as to the best naming structure :sweat_smile: My first thought is to name them what they are: containerized desktops or layered operating system images. I’m curious as to folks thoughts about image mode as a name; I think of it as being a descriptor of the workflow versus the actual end artifact… (Note this specific post is my personal thoughts on it, not official ones from the initiative!)

8

Yup, I’ve read that proposal and talked with @cverna about it. I think there’s a lot we can do here as a group to help all of us move forward together.

1 Like
9

Ha, a great set of questions. At the moment, I think the initiative described in Initiatives/Fedora bootc - Fedora Project Wiki is a bit broad. It was necessarily broad in the beginning as it was pure exploration on what was possible. Now we can tighten up what we’re targeting and why as we’ve gotten a year to explore.

My read of what an initiative is in Fedora is that it is an explicitly temporary structure that needs to reach a specific goal (or goals). In other open source communities, similar structures deliberately do not actually own anything so that, when the collaboration across the entire project is complete, nothing is lost when the structure dissolves. (I absolutely refuse to use business-y terms here :stuck_out_tongue: ) . Think of it more like an initial committee, made of representatives from various groups, that identifies blockers and negotiates how work will be done to the betterment of all, rather than a group of people tasked with code or infrastructure explicitly. Ideally, then, when this initiative dissolves, all that is going away is the meetings and chat spaces, but the actual work completed that it enabled remains.

Some concrete goals I can think of (some from @cverna’s work, some from what I’ve heard overall):

  • Collect and share experiment results, feature requests, and blockers for using Konflux for image mode builds.
  • Identify duplicate work across SIGs (CoreOS, IoT, etc.) and define a single workstream and owner.
  • Recommend creation of a SIG or some other formalized structure to own base images, extension libraries, and system extensions for various builds.
  • Collect and share feature requests and bugs to improve upstream bootc.
  • Identify and empower proper owners for all ongoing work to maintain and continue development of any solutions we come up with in a way that does not create single points of failure (ref the classic xkcd: Dependency) or a complicated structure that the project overall cannot maintain.
  • Attract new contributors to help with new work.
3 Likes
10

Thanks a lot @nimbinatus for putting this together :blue_heart:

I really like the proposal to consolidate on “Image Mode” to bring more clarity :100: . This is also a great chance to make Image Mode an exciting and core part of Fedora :fedora: .

The workflow for customizing, building, and releasing the OS is key in Image Mode. I’d love for us to make that workflow easier to experiment with, especially for newcomers. What Universal Blue did with image-template :blue_heart: is a great example, we could build on that or draw inspiration from it.

It might be also an opportunity to look at the fragmentation we have with fedora-bootc, Fedora CoreOS, and Fedora IoT. Having separate docs, meetings, and trackers is confusing for users and splits our focus. Unifying them under a single “Image Mode for Fedora” could be a something to explore.

9 Likes
11

Fell in love with image-based fedora, and love where this is going! Might I add, in addition to

Maybe Fedora could also take a look at BlueBuild? It was a part of Universal Blue, but got split because diverging in scope. This could be interesting for people that want to make their own images in an easier way.

Could Fedora work with these projects? Maybe implement something similar (or even the same thing) directly to upstream so that downstream (Ublue, etc.) uses that as an upstream-supported method instead of creating 2 (or more) different methods for each project?

4 Likes
12

Thanks for kicking this off, Laura! I’m excited to see this take off, as I think it could be a good model for how we can drive more innovation across Fedora.

In support of more innovation, I would love to see this idea of “a new space” find a way to co-exist alongside the reliable engine that has made Fedora successful so far.

The current image-based projects (Atomic Desktops, CoreOS, IoT) have a varying level of integration with the existing Fedora systems, both technologically and ideologically. And I think that has been part of the difficulty in finding support and popularity outside of the folks that do most of the the maintenance and development work for those projects.

I believe making a space adjacent to Fedora where interested participants can have more leeway to experiment with ideas that would normally be disruptive to the usual Fedora processes will ultimately benefit the community, even if it may take multiple releases to see those experiments bear fruit. Perhaps something akin to the CNCF framework, where projects go from Sandbox → Incubating → Graduated.

5 Likes
13

Yeah, on the business side, we’ve never figured this out either. Calling them “image mode images” feels a bit heavy :wink:

1 Like
15

Just catching up, and I love all of the ideas and discussions in here! Let me address some :slight_smile:

100%! There was a discussion in the upstream bootc project’s community meeting today about this. I suggested the same cookie-cutter idea from the Python world to go with that, and so upstream might provide a great starting point.

On this, I’m not opposed, but to be clear: How separate are these subprojects? Would it be better to have a dedicated group building and maintaining base images, and then these subprojects consume those base images and focus on the user needs of those specific groups? Someone upstream in bootc mentioned using the IoT version, and they had specific needs. I almost envision a base image SIG, with subprojects focused on specific use cases (maybe sub-templates? opinionated layering for different use cases?). Does that make sense?

Love the idea of looking into BlueBuild! I think partnering with other projects is a really healthy thing for a community to do, and it would be a great way to grow everyone’s community to the benefit of all.

100% agreed! That’s kinda why I was thinking of an experimentation SIG, or a “sandbox” SIG, that allows fast iteration that can co-exist in the same community without disrupting the production of the current desktop “package mode” version. This image mode initiative is a great opportunity to try it out and see if we can make it work as a community. Experiment, maybe fail a bit and learn from it, see if we can grow that way. The Kubernetes community’s governance structure allows for exploration of new tech through working groups (and yes, I did borrow from this idea for some of the proposals here).

Definitely want to find out what others are thinking, and naming things is hard! Hopefully throughout this discussion, we can come up with something as a group :smiley:

These are great questions! I’m going to put my upstream bootc community architect hat on for a moment to reply. I think knowing about and exploring what other groups are doing and seeing if there’s spaces to work together on needed features for upstream is a good thing. It’s healthy! I do think of all of the different operating systems using the bootc toolchain as midstreams or downstreams of bootc, like this:

    flowchart
subgraph upstream
  bootc 
end
subgraph midstreams
  bootc --> fedora[Fedora Image Mode base image/artifact]
  bootc --> opensuse[OpenSUSE base image/artifact]
  bootc  --> ubuntu[Ubuntu base image/artifact]
  bootc --> centos[CentOS Image Mode base image/artifact]
end
subgraph downstreams
  fedora --> bazzite[Bazzite artifact]
  centos --> bluefinlts[Bluefin LTS artifact]
end

(*edit - Also want to do a big callout to bootcrew folks for their work on stuff like Ubuntu/Debian and all working with the bootc toolchain! I don’t know if the OpenSUSE folks or Ubuntu folks are directly involved (it’s moving very quickly and I’m working on catching up), but this is a representative diagram as an example to explain my point.)

It might make sense to think of this initiative as a great place to define how to talk with other projects, and then what work can be done to push back upstream in partnership with other groups. And also, this initiative could be a way to surface to upstream bootc a desire from midstreams to work with other upstreams like ParticleOS or suggest ways of doing so, though I would expect that actual partnership between bootc and ParticleOS to be done in those spaces upstream. Does that make sense?

9 Likes
16

very peripherally involved, and mostly through some poking at things with the Universal Blue folks. At the moment, there’s no “official” driver from SUSE, or in the community, for openSUSE bootc images, beyond what little poking around I’ve been doing.

(edit: there might be other folks poking at it, I’m just not aware of them)

1 Like
17

I don’t know how relevant this is, but I found this a couple weeks ago: openSUSE Conference 2025 - Atomic OS Updates via OCI Images

1 Like
18

I really like where this is going, I tried to put together some ideas that could result in a new delivery model for Fedora’s “Image Mode”. These ideas comes from different conversations, the following is not perfect and is a conversation starter more than anything else.

We could provide a minimal set of bootable disk images (ISO, AMI, QCOW2, etc.) whose sole purpose is to run bootc switch.

This approach allows us to deliver editions like CoreOS, IoT, Server?, and Cloud? as pure OCI containers. The base disk image acts as a universal installer, pulling the desired OS experience from a container registry.

This model supports two primary workflows:

Direct Consume: A user boots a standard disk image and immediately switches to a pre-built Fedora edition.

  • Example: User downloads the Fedora Workstation installer, during the installation they select Image Mode, the installer is pre-configured with quay.io/fedora/fedora-silverblue:43

Build Your Own: A user maintains their own Containerfile (based on fedora-bootc or an atomic desktop) to create a custom OS.

  • Example: On AWS, start a fedora-bootc-43.ami and use cloud-init to run bootc switch quay.io/cverna/my-fedora-minecraft-server.

We could then consolidate the creation of custom Fedora versions using tools like image-template or BlueBuild. These community-built versions could be officially recognized under the Fedora Remix umbrella. Under this model, even an official edition like Fedora CoreOS or IoT could become a Remix, delivered just as a container.

5 Likes
19

Interestingly enough I had a similar idea and proposed this over in creating bootimages in Fedora for bootc (#77) · Issues · Fedora / bootc / Issue Tracker · GitLab - I didn’t know if this discussion forum post was the right place because I didn’t know if the bootc team would want that, but happy to discuss it here too.

2 Likes
20

The openSUSE folks just started showing up in the upstream CNCF bootc channel on Slack :slight_smile: I’m expecting some “official” community openSUSE artifacts will be coming down the pike soon!

1 Like
21

You’ve been joining the initiative calls, so you’re part of the initiative :stuck_out_tongue: That’s a great thing to discuss here as a milestone! Remember that bootc is the upstream for this initiative, so we can take this in the direction that Fedora needs and offer to push upstream anything that might help the upstream community, too.