Comments (2)
Hi, thanks so much for filing this! At a quick glance, I'd say there's indeed 85% overlap between the goals and methodology of the projects. But there's a lot of interesting stuff in that remaining 15% 😄
First and most obviously, bootc is a brand new project written mostly by one person with little documentation and no production use. Whereas it looks like Kairos is much more mature. But the point is that the current backing code of bootc (mostly ostree and the new ostree Rust) is also very mature with lots of production use - this is just a thin new "frontend" to it. (There's literally just ~500 lines of code in this repo today, though that will change once #30 lands).
I am totally open to collaboration! I think once bootc progresses a little bit we will start having community meetings indeed, or to piggy-back on the podman ones for 5-10 minutes perhaps.
I'd also be open to joining Kairos community events. To start, I'm now in the Matrix channel.
Offhand, some things in that remaining 15%:
- A major point of bootc is that making custom images is literally the same process as application images. What you push to a registry is exactly the same filesystem as what's pulled and booted, whereas it looks to me like Kairos is partition-oriented, so has an extra step where an ISO is created and pushed to a registry? I need to dig into this a bit more.
- This isn't stated directly but for me bootc has a toplevel goal to enable seamless in-place updates for existing ostree users. Because we have a lot of production users we can't just drop or even require to reprovision.
- bootc aims to support all Linux types, not just Kubernetes nodes. Specifically including "standalone" and non-cloud systems, like IoT and desktops. This leads into the next bit:
- The details around partition setup, specifically things like
/etc
being ephemeral clash with the above. On a desktop, I don't want my WiFi configuration stored in/etc/NetworkManager
to be flushed on reboots. Similarly for bare metal servers, static IP addresses are a real use case. On a cloud, sometimes I do want/etc
flushed, sometimes I don't. - bootc (and ostree) have first-class support for SELinux. This affects a rather surprisingly large set of design choices in implementation.
- bootc is not attempting to do things like build cloud images and ISO images itself; I think we should leave that to distribution tools. Or at least, maybe this project would have "demonstrators" of that.
- We've been making an increasing investment in Rust for the last few years from both teams that are involved in this project (coreos/ team and the containers/ team). Obviously Go will be here for the remainder of my career at least, but I've been repeatedly burned by its "superficial simplicity" and using Rust for bootc was a very deliberate choice.
Just curious, how does it handles upgrades without ostree? is it a/b style?
It doesn't at all today, but indeed part of the idea is that we should also support that flow. I'd like to investigate standardizing or at least collaborating on shared code for things like how to store and manage raw block devices stored in a registry. The obvious thing of just sticking a disk image in a tar layer is painful from a bandwidth perspective; in coreos we have tooling called "osmet" that synthesizes disk images from ostree and tar (much like jigdo).
Thanks again for filing this and bringing Kairos to my awareness. Looking forward to continuing this conversation and collaborating!
from bootc.
Thanks for the quick answer!
Hi, thanks so much for filing this! At a quick glance, I'd say there's indeed 85% overlap between the goals and methodology of the projects. But there's a lot of interesting stuff in that remaining 15% smile
First and most obviously, bootc is a brand new project written mostly by one person with little documentation and no production use. Whereas it looks like Kairos is much more mature. But the point is that the current backing code of bootc (mostly ostree and the new ostree Rust) is also very mature with lots of production use - this is just a thin new "frontend" to it. (There's literally just ~500 lines of code in this repo today, though that will change once #30 lands).
I am totally open to collaboration! I think once bootc progresses a little bit we will start having community meetings indeed, or to piggy-back on the podman ones for 5-10 minutes perhaps.
Awesome :) looking forward to hear more
I'd also be open to joining Kairos community events. To start, I'm now in the Matrix channel.
Offhand, some things in that remaining 15%:
* A major point of bootc is that making custom images is _literally the same process_ as application images. What you push to a registry is _exactly the same filesystem_ as what's pulled and booted, whereas it looks to me like Kairos is partition-oriented, so has an extra step where an ISO is created and pushed to a registry? I need to dig into this a bit more.
That's the same approach of Kairos. The image being pulled can be run with docker, podman, etc as a standard application, but still bootable from Kairos without any container engine (it does loopback mount the image behind the scene). As per partitioning, it is completely flat, and used just to store bootable images: https://kairos.io/docs/architecture/immutable/#design
Additional tooling is in place to convert a container image to a bootable ISO, or a raw disk.
* This isn't stated directly but for me bootc has a toplevel goal to enable seamless in-place updates for existing ostree users. Because we have a lot of production users we can't just drop or even require to reprovision.
I see! that's interesting and could be a meeting point. I always wanted to explore an ostree backend for Kairos, and maybe bootc
might be at hand exactly for that.
* bootc aims to support _all_ Linux types, not just Kubernetes nodes. Specifically including "standalone" and non-cloud systems, like IoT and desktops. This leads into the next bit: * The details around partition setup, specifically things like `/etc` being ephemeral clash with the above. On a desktop, I don't want my WiFi configuration stored in `/etc/NetworkManager` to be flushed on reboots. Similarly for bare metal servers, static IP addresses are a real use case. On a cloud, sometimes I do want `/etc` flushed, sometimes I don't.
Right, this indeed isn't really obvious from our docs but Kairos while has primarly focus for Kubernetes it does handle well also outside of it. /etc
is ephemeral, but partially as it can be completely customized to be flushed or not. Indeed for Kubernetes we need several paths to be writable and persistent into /etc
, as well as some systemd
related ones.
* bootc (and ostree) have first-class support for SELinux. This affects a rather surprisingly large set of design choices in implementation.
Altough we don't support it directly yet, it is in our roadmap and I do agree it tends to be a can of worm, but I see a lot of crossing points between our projects!
* bootc is _not_ attempting to do things like build cloud images and ISO images itself; I think we should leave that to distribution tools. Or at least, maybe this project would have "demonstrators" of that.
👍
* We've been making an increasing investment in Rust for the last few years from both teams that are involved in this project (coreos/ team and the containers/ team). Obviously Go will be here for the remainder of my career at least, but I've been repeatedly burned by its "superficial simplicity" and using Rust for bootc was a very deliberate choice.
👍 I don't have a strong opinion here, but I welcome Rust. I think languages are just barriers to what someone wants to really achieve and the computer, so I don't mind, and there are obviously better choices than others based on the scope of the software.
Just curious, how does it handles upgrades without ostree? is it a/b style?
It doesn't at all today, but indeed part of the idea is that we should also support that flow. I'd like to investigate standardizing or at least collaborating on shared code for things like how to store and manage raw block devices stored in a registry. The obvious thing of just sticking a disk image in a tar layer is painful from a bandwidth perspective; in coreos we have tooling called "osmet" that synthesizes disk images from ostree and tar (much like jigdo).
For kairos we don't store separate disks and push them as containers images - we flatten the container image in runtime when we write it to disk so there is still one source of truth - you can run the container locally as an app, or just boot it seamlessly.
Thanks again for filing this and bringing Kairos to my awareness. Looking forward to continuing this conversation and collaborating!
Thanks to you! It was good to understand to set expectations and understand where bootc
is heading to, I'll be joining community events as soon as they are up!
from bootc.
Related Issues (20)
- Document setting kernel arguments (kargs) HOT 1
- check composefs compat when rebasing
- bootc switch error: ostree-tar: Processing deferred hardlink HOT 5
- post-pull pre-stage stage HOT 5
- API review checklist
- tracker for "physically bound" containers HOT 1
- docs: Add a "migrating from rpm-ostree" doc
- uid/gid drift possible when switching between different host builds HOT 9
- authfile paths can't be absolute HOT 10
- Add requirement on exact matching host architecture HOT 1
- stabilization tracker: `bootc image copy-to-storage`
- bound images fail in bootc-image-builder HOT 6
- install to-disk: Check for mounts
- tracker: bootc container storage
- Unable to do bootc image copy-to-storage HOT 1
- tests: tmt runs all tests in one vm HOT 3
- Failed to run bootc install to-existing-root on ppc64le host when using MBR partitioning HOT 3
- Opening ostree/bootc/storage: No such file or directory HOT 2
- Build Fedora 40 anaconda-iso failed on aarch64 HOT 1
- Image Pulling Error During Build in Podman Desktop
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bootc.