Renewing the Fedora bootc (now image mode) initiative

Project Discussion
,
22

Offhand I think a deliverable from this could start from what we want to have appear on https://fedoraproject.org

Right now it’s all “consume” based and doesn’t mention image mode or bootc.

2 Likes
23

Naming things is hard.

This would all be a lot easier if better decisions were made years ago by other people so that instead of “containers” we’d all be using “sandwiches” and thus had a better mental model for this stuff that involved easily..digestable…layers. We should be having debates right now on whether these things should be called dogwood mode or club mode.

more seriously…

Image mode feels like a workflow and not a named output.

If we position the base image correctly I fully expect the tooling/service we provide to publish customized outputs will need to be collectively branded something like “image mode remixes”. I’m not sure individual outputs will want that. We may want to have a space specifically for the “image mode editions” assuming we still have the concept of editions.

2 Likes
24

This is why, back when I was FPL, I made a big push to distinguish “Fedora Linux” the thing we produce from Fedora, the project. We should have room for this in Fedora, without breaking the Fedora Linux people know and love.

3 Likes
25

Having spent a couple of years inside the CNCF collective, and a few years prior to that in its orbit…I will say…

I would love to adopt a subproject lifecycle approach here in Fedora similar to the CNCF’s that focused on sustainability and put some requirements on what a subproject needs to agree to… to be considered healthy once it leaves the sandbox.

I don’t think Fedora will ever get to the complicted mess that the CNCF project landscape looks like, but there’s room for overlapping things for sure..we just need to make sure we setup those things to be sustainable..and be honest when they are not…and make sure we stop doing them if they aren’t getting enough collaborative contribution. And we can only do that if we agree very early on what enough collaborative contribution is.

I admire the intent of the CNCF project stages as gates on project health and maturity.
I’m very sure Fedora could use something very similar to the CNCF sandbox project concept, with some clearly stated goals to achieve for building a reasonable self-motivating/self-governing group of contributors and not just focused on user adoption. We’d have to think hard about the incentives that would help subprojects move through the gates. And what goals projects sitting in the different lifecycle stages need to focus on. The details will not look like the CNCF at all, but the sustainability focus at each gate might.

But what I think is just as important is the CNCF TOC’s role in doing health check reviews of both incubating and graduated projects to ensure they are still sustainable efforts and they haven’t walked themselves into a situation where what everyone expected to be a team of multiple maintainers collaborating together in a graduated project hadn’t reverted back to just 1 or 2 active maintainers trying to run hero efforts to make up for the fact that the trusted maintainer/commiter team evaporated. There’s a particular story about one the CNCF projects I love to tell late at night at a firepit during spooky season as a cautionary tale. The CNCF lifecycle process helps setup projects to be sustainable, but it wasn’t an assured outcome. The TOC health checks are a useful mechnism to get projects back on track, or make the decision to sunset them as an output.

Fedora probably could use both the lifecycle gates and the health check process.

3 Likes
26

Great idea! I think that’s kinda what @cverna was bringing up here: Renewing the Fedora bootc (now image mode) initiative - #18 by cverna, and I like the idea of the goal of a section of the landing page being the collection of the artifacts’ landing pages, like written here:

Maybe then the template system would be a link at the bottom, along the lines of “Can’t find the version you need? Use this tool to make your own layered image!”

1 Like
27

From a user presentation standpoint, I don’t think that we need to do much to change how we position the current editions outside of adjusting how Fedora Atomic Desktops are placed. For the end user, they just want to use an OS that works, and so we provide them information based on an OS that solves a particular use case. In the pages and linked documentation we can provide updates and specify how some of the editions are now based on bootc or Image Mode, but I don’t think their positioning as container host, IoT OS, atomic desktop needs to change. How the OS is delivered is secondary to what the variant will do for them.

That being said, I do think that internally for contributors or separately for evangelism we could benefit from a website that talks all about Image Mode. That’s where I would list all the editions and spins that use bootc and we can talk about how great it is over there. It’s potential contributors or people who need to understand bootc who will benefit from that.

On the topic of renaming Fedora Atomic Desktops, I would recommend not doing so. Doing the initial name change took a long time to do, and now that it’s been this way for a while we have successfully gotten the broader community to use the new term. It was a meme the way people stumbled over how to refer to these variants, so I wouldn’t want to mess with that progress. It’s also helped with the adoption of the term “atomic” over immutable to further clarify how these desktops differ from other Linux distros. The conversation around how these spins work has evolved. Image Mode can be the umbrella term for everything in order to tie it to Red Hat’s offering, but I don’t think changing the names is needed.

12 Likes
28

Very good points!

I’d like to emphasize @joseph ‘s point: there’s a user (“consumer”) perspective on use case in terms of content (desktop environment, package choice) and handling (piecewise updates vs atomic updates). This is where naming and presentation on the download site matters. “Atomic” serves this purpose well, as well as naming edition/spins by purpose and/or desktop environment (which we finally agreed on at least for most of them).

“Image mode” says nothing to users and is an implementation detail at best. Indeed, I find the term unspecific and easily confused with all those image deliveries that we provide already today - ISO image, qcow image, … Add kernel image and UKI to that. In other words” “image mode” is not even an implementation detail but an umbrella term. “bootc” is specific, “ostree” is; “[OCI] container” is less specific but at least more so than “image”.

5 Likes
29

I’d have to agree here that the term “Atomic” is doing a lot of work in the community already. I believe it’s already understood that Fedora Linux (packages) and Fedora Atomic (images) are 2 separate deliverables. I’d vote to leverage the word “Atomic” as it already has mind share.

In order to distinguish between the different atomic flavors (images) maybe it makes sense to slightly adjust branding slightly? So anything powered by images/bootc is labeled under “Atomic”. Example: Fedora Atomic IoT, Fedora Atomic CoreOS, etc. I think Silverblue and the others already follow this and fit right in. We then adjust the website to say anything Atomic is based on bootc and provide info accordingly.

I really like Laura’s suggestion of a quick selector on the Atomic page for what flavor you want and then if you can’t find what you want then link to an image builder tool (bonus points if we get that upstreamed to bootc directly).

I’d vote to leave all the SIGs like IoT, Cloud, etc continue functioning like they do today. Then, the goal of the Fedora-Bootc initiative would turn into helping all these editions ship bootc images. We already have a base Fedora bootc image and the initiative would help maintain that until we get a path forward on who will own/maintain that. It would be the various Fedora SIGs responsibility to come to the Fedora Bootc initiative to get help shipping their editions as needed.

I’m new so maybe I’m missing context but I think this would work. I would love to see the initiative focus in its next phase and deliver images powered by bootc.

3 Likes
30

We should probably leave the Atomic Desktops brand as is; it was renamed recently and the name is clear and recognized.

However, I still think that the use cases for Fedora CoreOS and IoT feel narrow, and we could benefit from consolidating their documentation and strategy.

I understand that “Image Mode” is not really well established and self descriptive. For me, this initiative’s value isn’t just in the bootc delivery mechanism, but in leveraging the entire OCI container ecosystem, including tools for CI/CD and security scanning. This is what is under the Image Mode umbrella. The focus should be on this complete workflow and its tooling, not only on the deliverables.

8 Likes
31

You can use the word Atomic as the brand name and the word image to describe what it is.

Just using the word image, however, is not enough: you also have explain what is meant by it. What makes an image an image? You have to explain that it’s a way to keep the integrity of the complete os. Even deeper, you can explain that this is achieved by creating a hash-tree of the complete file system (excluding some directories).

32

If ya’ll can get to the “base image that acts as a universal installer” that gives me a way out of the trap of the infinite number of editions problem that would be amazing.

I would love to be be able to hold up that universal installer image as the naming things is hard edition that opens up a portal into a universe(or is it multiverse?) of bootc switch enabled experiences.

<Place bootc switch parody lyrics of the song “Pure Imagine” as sung by Gene Wilder in 1971 Willy Wonka movie here>

1 Like
33

We could have done this a long time ago, even before bootc. But there’s no staff to develop Anaconda to have that capability. Heck, SUSE’s Agama already does this, no OCI stuff required.

2 Likes
34

Not to drift too much from the focus of this thread, but I do think having editions has benefits from a marketing perspective for the user. I wouldn’t want to see us go down the route of doing away with editions and spins entirely in favor of a universal installer because as I understand it there are important distinctions that we maintain through this scheme.

3 Likes
35

This is such a great discussion – really appreciate everyone’s thoughtful input here!

I’m excited about the idea of a Universal Atomic Installer approach. One thing I like about it is that it could give Editions and Spins the flexibility to make their own decisions without getting bogged down in definitional debates. While I know these distinctions matter to some parts of the community, I wonder if we might make more progress by focusing on the technical solutions rather than the categorizations.

One small naming thought: when we’re discussing this within Fedora, I find “Atomic,” “ostree,” or “bootc” to be clearer and more precise than “Image Mode” – but I totally understand the reasoning behind consolidating under one umbrella term for the initiative.

Thanks again for driving this conversation forward! Looking forward to seeing where this goes.

2 Likes
36

I think we shoud keep different names as they are different experiences and target different users. What we want to do with the Image Mode name is to unify the developer experience around how bootable container systems are built in Fedora.

Then each output of that developer experience should have a different name because it will be a different user experience.

  • For Atomic Desktops, the user experience is downloading an ISO to install a system and using Flatpaks for apps.
  • For CoreOS, the user experience is downloading a disk image or booting one directly in the cloud, using containers for apps, and automating provisioning via Ignition.
  • etc. for IoT

But for all of those, we want the developer experience to be the same, whether it is for building them, extending them locally, building a derivative image or building something completely new.

I’m not convinced users will see value in a universal installer. At best, it could be a Silverblue/Kinoite unified one but that’s it, and it would already be too big to be of use for most users. We would also have to do the work to let users select which session to start or add something to switch sessions on the Live ISO.

For server use cases, you either want something really small and download from the network or you want something that is exactly (or close to) what you need and install offline.

1 Like
37

I’m sorry, but after that post I don’t know any more what “image mode” is. Apparently it’s neither about atomic nor about disk images.

“Developer experience” is sales wording which says nothing. Besides “experience”, it might help say who you mean by “developer”. It’s common source of misunderstandings.

38

There is no formal definition for the Image Mode term, just like there is no formal definition for immutable Linux distributions and people are using it to refer to NixOS, openSUSE MicroOS, Talos Linux, etc.

Generally, all image based Linux systems feature atomic updates (otherwise there is no point). See the list of projects represented at the Image Based Linux Summit for examples: 2024 09 24 Image Based Linux Summit | UAPI group generic documents and meeting minutes.

But not all of them have disk images. We don’t offer disk images for Fedora bootc or Atomic Desktops for example. If we did it for Atomic Desktops, we would still not offer those to users front and center, as the main use case is installing from an ISO, not a disk image.

From my perspective, the Image Mode term should describe the way we build, develop and distribute Image Based systems in Fedora. We want to focus on Bootable Containers as the primary option, which is what we are discussing here.

But note that the Fedora Atomic Desktops are currently not Bootable Container based, so they would not be under that name right now, but hopefully should be in the future.

I gave examples above of what the user experience is for Atomic Desktops and CoreOS. The developer experience is about what tools people are using to build the container images, disk images, ISOs, etc. for users to download and use.

2 Likes
39

Aye, this is something still rattling around in my head. As a developer of a MicroOS based desktop system, everybody kind of understands what “immutable” means, but it’s really not accurate, nor is the MicroOS model “image mode” or “image based” like something bootc based.

Not that it directly has anything to do with Fedora and their “immutable” products, our model is atomic, but not image based, and that’s pretty common for a number of the Fedora Atomic “peers”

1 Like
40

Hey there, folks! Love that there’s so many people chiming in and participating! I’m just getting to catch up to everyone now, and y’all have been busy!

We’re over two weeks out from when I opened this proposal, so I want to summarize and hopefully define next steps for us so we can get moving.

Naming
We’ve got a lot of discussion around naming things. We all know naming things is hard :slight_smile: I’d like to avoid bikeshedding on the name if possible as that will hold us back and keep us from getting something done. I think a clear need, though, in watching this thread is that we need some stakeholders identified here to define a naming strategy that includes user feedback and project history, as well as a cloud native viewpoint considering a number of adopters and potential adopters live in a cloud native world. In looking at this org chart, I think we need stakeholders on this initiative from the following teams:

  • Marketing
  • Docs
  • CommOps (Ambassadors) for feedback loops
  • UI/UX or Design (or maybe it’s the Fedora Mindshare Committee for the website?)

Anyone want to volunteer to step forward? Am I missing a team for this list of stakeholders?

For now, while we’re still thinking through official names, I’m going to say we keep “image mode initiative” since I can’t really use “bootc initiative” and search on the wiki or on Discourse here will be easier for someone curious.

–

A big theme here has been consolidating work so we’re not duplicating work across multiple subprojects. We’re interested in the idea of a universal installer, a single unified user experience for building artifacts based on the bootc toolchain, and base images that can be used across subprojects.

Some concerns that came up in the weekly meeting[1] included dealing with how we handle critical bugs that only affect the artifacts (and gating CI) and getting package gating in alignment across artifacts.

So, here are some other major working points I can identify:

Base Images

Here, the big goal is building a strong base image that can be used by multiple subprojects and anyone else deciding to use bootc with an “atomic” base of a Fedora kernel to build their own artifacts. This group could also be focused on documentation on how to use these base image(s), and maybe even on the universal installer idea. I think we need stakeholders on this initiative from the following teams:

  • CoreOS
  • IoT
  • Workstation/Silverblue
  • Quality
  • Security
  • Docs
  • Containers (for the layering of Flatpaks on base images in an installer?)
  • UI/UX (for the installer)

Anyone want to volunteer to step forward? Am I missing a team for this list of stakeholders?

Pipelines

The main goal I’m identifying here is creating a sustainable delivery pipeline with the expertise and volunteer base to maintain it alongside the infrastructure needed to deliver the installable Fedora systems. It also allows for the exploration of Konflux as a tool and the creation of a set of contributors with the skillsets needed to run Konflux for all of Fedora.

We also need to address any automatic gating that needs to be done as part of the pipeline to block buggy artifacts from being released into the wild.

I think we need stakeholders on this initiative from the following teams:

  • CoreOS (as the current group using Konflux)
  • Release Engineering
  • QA
  • Docs

Anyone want to volunteer to step forward? Am I missing a team for this list of stakeholders?

–

Experimental things

Another theme in this thread is somewhat separate from this initiative specifically, and that’s the idea of a space for experimentation and fast iteration on shifts like this. This initiative is a good opportunity to use as a bit of a testbed for trying these things as there are a lot of newer things and technologies to try out, and the upstream project (bootc) is coming from a cloud native space where many of these ideas are already in place. A possible goal of this initiative is the creation of some SIGs/specific groups, such as a group to own the base images, so there’s additional space for exploring that we can discuss with the rest of the community as we go. I think our watch phrase will be “Explore out in the open” for much of this initative :slight_smile:

There will be many stakeholders—the whole community!—so I don’t want to name specific teams or people here as much as I’d say there will be an active posting to the forum overall on ideas and thoughts that come, so respond as much as possible.

–
Expected Milestones

  • Fedora 44 (April 2026)
    • Self-sustainable Konflux pipeline in place for dev, QA, and staging for base image creation.
    • Hosting solution set up for base images and other artifacts, whatever that might be (existing or new).
    • Beta base images and beta subproject artifacts released on a regular cadence in said pipeline.
    • Initial testing harnesses and processes complete for base image creation and QA.
    • Initial documentation in beta for base images, artifact generation, and pipeline use.
  • Fedora 45 (October 2026)
    • Production Konflux pipeline in use and well-documented.
    • A team of contributors is in place and established to support base images.
    • All elements have identifiable ownership teams of 3 or more contributors.
    • All base images and subprojects are shipped with production versions of their artifacts, with a possible nightly/unstable build available for development work.
  • After Fedora 45 (2027 onward)
    • Initiative is completed and dissolved. All work, code, infra, etc. owners have been identified and onboarded as a permanent end state.

Next steps

  • I’ll write up a more formal initiative proposal with everyone’s thoughts to share with the Council.
  • Please let us all know here if you’re a stakeholder who wishes to ensure you get on my “Hey, you coming?” list for meetings :slight_smile: Fair warning that I will come find you and politely remind you of meetings and things to weigh in on.
  • You all tell me what I’ve missed or gotten wrong.[2] After all, this is a very long thread!

  1. Relevant parts are highlighted with the !info tag in the Meetbot Logs ↩︎

  2. (Someone is wrong on the Internet? The horror! Yes, it’s Halloween week :jack_o_lantern: ) ↩︎

6 Likes
41

I am not on the list of stakeholders per se but I’m interested in helping out with the base images (definition and documentation).

I’d be happy to help with this too! (Although this week and next week are very busy.)

2 Likes