docs: Add relationship-particles.md #252
Conversation
cgwalters
force-pushed
the
doc-relationship-particles
branch
from
b226e83
to
2644231
Compare
This original vision document from Lennart is great. Let's lay out a vision for why the bootc project exists and is different from this. Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
doc-relationship-particles
branch
from
2644231
to
28b9bac
Compare
github-actions
bot
added
the
documentation
|
|
||
| The "particle" proposal mentions that the desktop case is most | ||
| interesting; the bootc belief is that servers are equally | ||
| important and interesting. In practice, this is not a real point |
There was a problem hiding this comment.
I've just finished reading the particle paper after this tipped me off to it (so thanks for educating me!). I think this is an oversimplified take on what the paper is saying. The key point I took away is that the desktop case is a superset of the complications that arise in server/embedded (maybe your point here is that you disagree with that assertion?). So if you concentrate on the desktop case, then it follows that you also cover 100% of the server case as well (and then some).
There was a problem hiding this comment.
(maybe your point here is that you disagree with that assertion?).
Yes, this. There are some things that are hard on servers that do not exist on desktops in isolation; particularly "distributed systems" interactions.
There was a problem hiding this comment.
This reads great to me! There is some things that could be expanded on, like how OTA transport protocols differ between traditional ostree and bootc.
But this is super detailed already, I enjoyed reading it, it's a nice overview.
I know there is interest in the community in reducing the number of bytes that go over the air during an upgrade. So that's just one area in particular that springs to mind.
| files. | ||
|
|
||
| What bootc builds on top of that is to target a specfic container image rootfs | ||
| that is part of the "physical" root. Today, this is implemented again using ostree, via the `ostree=` kernel commandline argument. In the future, it is likely to be a `bootc.image`. |
There was a problem hiding this comment.
In the future, it is likely to be a
bootc.image
It's not clear to me from reading this, what a bootc.image is.
Ultimately, the initramfs will contain logic to find the desired root container, which
again is just a set of files stored in the "physical" root filesystem.
I do try and lean against using kargs these days, in a world where you use a UKI secured thing, there's no difference between using /proc/cmdline and a file in /etc in the initrd. It sounds like we are leaning the same way here.
Except sometimes firmware/bootloaders use it as a common namespace to communicate, which can be messy. Somehow I run into a couple of cmdline pollution issues a year.
But it does have an advantage I guess in that it can be useful for debugging in grub. Although you can just edit the initrd also to debug things, so, meh...
There was a problem hiding this comment.
I do try and lean against using kargs these days, in a world where you use a UKI secured thing, there's no difference between using /proc/cmdline and a file in /etc in the initrd. It sounds like we are leaning the same way here.
Yes, this is a good point. In ostree today we go to some effort actually to avoid changing the initramfs when only userspace changes - and kernel args are really the only way for us to reliably pass state between generic bootloader setups and the initramfs.
But you're right I think in a sealed setup we should indeed not use kargs.
|
Overall I think this looks good to me. Maybe we should mention the optional approach of a transient /etc. I think that makes a lot of sense for many types of sealed systems. |
|
If we decide to add transient /etc info, lets do it in a different PR. |
|
Question on this... As of today is rpm-ostree a build time dependency of bootc? Like how is the initrd built server side? A naive search of "dracut" in the bootc repos, returns nothing |
This is covered by https://containers.github.io/bootc/bootc-images/ |
|
I should have more clear: As of today is rpm-ostree a build time dependency of a bootc image? (compose time dependancy might be better wording) Thanks for the link @cgwalters , the answer is yes from reading https://containers.github.io/bootc/bootc-images/#building-bootc-compatible-base-images but I didn't word my question right. |
|
Ability to use everyday dnf at compose-time: https://containers.github.io/bootc/bootc-images/#deriving-from-existing-base-images rather than just in a temporary way via |
This original vision document from Lennart is great. Let's lay out a vision for why the bootc project exists and is different from this.