[Sandbox] bootc

[marrusl]

Application contact emails

Ben Breard - [email protected]
Mark Russell - [email protected]
Colin Walters - [email protected]

Project Summary

The bootc provides transactional, in-place operating system images and updates using OCI/Docker container images.

Project Description

The original Docker container model of using "layers" to model applications has been extremely successful. This project aims to apply the same technique for bootable host systems - using standard OCI/Docker containers as a transport and delivery format for base operating system updates.

The container image includes a Linux kernel, which is used to boot. The process for image creation, building, and testing, is done using standard OCI tooling, but the operating system payload runs “on the metal” of the device itself.

This allows the use of the OCI ecosystem as a common language for both the operating system and the application workloads.

Org repo URL (provide if all repos under the org are in scope of the application)

N/A

Project repo URL in scope of application

https://github.com/containers/bootc

Additional repos in scope of the application

No response

Website URL

https://github.com/containers/bootc

Roadmap

https://github.com/containers/bootc/milestones

Roadmap context

N/A

Contributing Guide

https://github.com/containers/bootc/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

The containers community currently has its own CoC. If accepted, it would switch to the CNCF CoC https://github.com/containers/common/blob/main/CODE-OF-CONDUCT.md

Adopters

https://github.com/containers/bootc/blob/main/ADOPTERS.md

Contributing or Sponsoring Org

www.redhat.com, www.fedoraproject.org

Maintainers file

https://github.com/containers/bootc/blob/main/MAINTAINERS.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

We believe that the bootc project brings the traditional “Linux distribution” into the cloud native ecosystem in a way that wasn’t possible before. Starting the process of moving bootc to the CNCF signals our intent as an upstream project to interoperate with the wider operating system ecosystem. Modifying and building operating system images predates the existence of cloud native by over a decade. Since bootc uses cloud native tooling that already exists, we feel that the CNCF is a natural fit for this tool.

Benefit to the Landscape

Bootc is a new Linux deployment method that addresses configuration, deployment, and automation. It allows users to converge their environments--from the OS up to the application containers--with a single set of cloud-native tools. This means the same security scanners, CI/CD pipelines, build tooling, etc that they use today to manage their containerized application stacks.

Over the last few years, the CNCF has extended Cloud Native "up" to platform engineering and AI. Acceptance of bootc will extend Cloud Native "down" to system provisioning, helping give CNCF end users complete control over their full stacks.

Cloud Native 'Fit'

Bootc allows usage of a common language to describe and manage operating system deployment pipelines, extending cloud-native patterns all the way to the metal (or virtual metal). The containers themselves are OCI (with a kernel inside). Creating the images uses common tools like podman, docker, git, and registries. These images are made the same way as existing application containers.

Following Cloud Native principles, Bootc system management can be done declaratively and immutability is enforced at runtime.

Cloud Native 'Integration'

As bootc is very new, it has not yet been integrated with existing CNCF projects. However, we see many opportunities for future integration, including:

• Kubernetes, especially Kubernetes provisioning tools like Kubeadm, KubeSpray, as well as build tools such as Kuberentes SIG Image Builder.
• Other bare metal provisioning tools like Metal^3 and MetalLB
• Cloud Native OSes like Flatcar and Kairos
• Other applications which might be deploying bare metal or cloud nodes, such as etcd and TiKV
• CI/CD projects like ArgoCD, Tekton, and Flux around extending to generic operating system build and management

Bootc depends on composefs (also being submitted for sandbox) for its backing store.

Cloud Native Overlap

Kairos: The bootc project has some overlapping features in containers, and also aims to be an operating system agnostic toolset. There’s more on this in containers/bootc#31. The scope and emphasis of the projects is different, but we hope to find common alignment.

Flatcar Container Linux: First there’s a fundamental difference in that Flatcar is an operating system that also includes some overlapping infrastructure tools, whereas bootc is just a tool, not an operating system. Bootc emphasizes the base OS image as a customizable container, whereas Flatcar emphasizes running the stock image and adding customization dynamically with Ignition and systemd-sysext. There are plenty of collaboration opportunities between the two projects which we look forward to exploring.

Similar projects

Kairos OS - https://kairos.io/

Landscape

No

Business Product or Service to Project separation

Bootc is strictly a public open source project. Image Mode for RHEL depends on bootc as a client tool and also produces a reference base image and higher level tools and integrations. The requirements for product usage are the same as they will be for any other OS wanting to build images with bootc. Bootc works with the Fedora community as well, so we already have practice keeping project and product priorities separate.

Project Domain Technical Review

The project plans to present and will update this application with the recording and notes after that time.

CNCF Contacts

Karena Angell, Emily Fox, Josh Berkus
Staff: Jorge Castro

Additional information

No response