Questions about Ostree and Ostree native containers

Ask Fedora
,
1

Hello Fedora developers and engineers,

 
I use Fedora Silverblue for quite a few years and believe I have a basic understanding how it all works, but despite of that I have a few questions. Some are about current version of Ostree and some are about the new version of Ostree with native containers. I will start with the questions about the current version of Ostree and after that I will ask the questions about the new version of Ostree (if it still will be called Ostree).
 
 

Question 1
Do I understand the working of Ostree right and does it work in the following way:

  • You have a object store and this object store stores all the references (hard links) to the actual files. The object store is not really a database, but are just text files on disk.
  • When you update the system, the object store is synchronized with the new version on the server (the repository) and after that all the new files are downloaded.

 
In an image it looks like this:

ostree
ostree1512×907 28.7 KB

Is my understanding right?
 

Question 2
Do I understand Ostree right and an image is nothing more than a snapshot of the object-store (with the attached files)? Because all the files are hashed together they form the image?
 

Question 3
By default Ostree only stores the last two deployments (the current version and the previous one. Is it technially possible to store more versions? For example the last three, four of five? There may not be a need for it, but I’m just curious.
 

Questions 4
If I have understood the wiki of Ostree native containers correctly, the new version will not download the object store and files on the server, but only a new container image (or a layer of it)?
If so, what will the roll of Ostree be? It will only be used as the versioning system?

On the server side you could create a object store out of the container image, but I guess this is not how it will function (not necessary or cumbersome)?
 

Questions 5
Is the below image the ultimate goal of Ostree native containers? As far as I know, there isn’t a Fedora base image yet, but wouldn’t this create a beautiful hierarchy of the Fedora Atomic versions? The goal is that someone only has the write a new container file to create a new version of Fedora?

Fedora native containers
Fedora native containers2245×1361 128 KB

 

Questions 6
And my last question: is another goal that in the near future you can change to new image live by using a combination of systemd softboot and ostree apply-live? Is the idea that you press on a button in GNOME software and that than the image is updated without the user knowing it? Maybe just a short flickering of the screen? Or should the user still have to log out and log back in?
 
 
As you can read I’m very interested in the future of Ostree!
 
Thanks for reading and possibly answering some questions :slight_smile: !
 
 

- Scott Trakker (my pseudo name on the internet)

2 Likes
2

Added coreos, ostree, rpm-ostree and removed server

5

Added ostree and removed rpm-ostree

6

Removed rpm-ostree

7

Added ostree

9

Ostree stores the content of the files indexed by their hash directly in the repo (/sysroot/ostree/repo/objects) with their metadata alongside. This is very similar to Git.

When you update, (rpm-)ostree pulls the new files & metadata into the repo.

Technically, there are no “images”, it’s “just a bunch of files” and each deployment (version of the system) is a tree hierarchy with all the files in them being hardlinks.

You can store as many as you want (only limited by disk space, notably in /boot). Right now you need to pin deployments to prevent rpm-ostree from removing them: support configuring host to retain more than two deployments · Issue #577 · coreos/rpm-ostree · GitHub

The new format is mostly a transport mechanism right now: The repo is moved inside of a container instead of being delivered as individual files from an ostree repo. The main difference is that it also include a checkout (deployment) thus you can manipulate the content of the OS like any other container. Ostree is still used to store the files in the repo and manage deployments.

Maybe for server-like systems, but in practice not for Atomic Desktops. There are significant downsides of doing it like that for Atomic Desktops. Maybe once those get fixed.

Integrating with systemd soft reboot could be doable. But in practice, updating without a login / logout or reboot is mostly not possible, notably for kernel updates.

2 Likes
10

Hello Timothée,

Thanks for answering my questions!!
 

Ostree stores the content of the files indexed by their hash directly in the repo (/sysroot/ostree/repo/objects) with their metadata alongside.

Does this mean that all the files under / are hardlinks to those objects in the repro?
 

The new format is mostly a transport mechanism right now: The repo is moved inside of a container instead of being delivered as individual files from an ostree repo. The main difference is that it also include a checkout (deployment) thus you can manipulate the content of the OS like any other container. Ostree is still used to store the files in the repo and manage deployment

Do I understand it right and the Ostree repo is part of the container that’s being downloaded?
Ostree has now become a sort of combination of a git-like and a Docker-like system? Can I paraphrase it like that?
 

Integrating with systemd soft reboot could be doable. But in practice, updating without a login / logout or reboot is mostly not possible, notably for kernel updates

It would be great to log out and log back in for normal updates and a reboot for updates with a kernel update!
 

Ostree native containers is now planned for Fedora 41. It will then use containers to download a new version of Fedora or will only a part of the technology be in place (and still use an Ostree repro)?
 

:slight_smile:

11

Yes, all the files under /usr are hardlinks to those under the repo in /sysroot/ostree/repo:

$ ls -i /usr/bin/ls
174099025 /usr/bin/ls
$ find /sysroot/ostree/repo -inum 174099025 2>/dev/null
/sysroot/ostree/repo/objects/b1/0e2396ce514a1eb7a450991c99189fb7842a0d37c5a960363b93af1a7fb4a3.file
$ ls -i /sysroot/ostree/repo/objects/b1/0e2396ce514a1eb7a450991c99189fb7842a0d37c5a960363b93af1a7fb4a3.file
174099025 /sysroot/ostree/repo/objects/b1/0e2396ce514a1eb7a450991c99189fb7842a0d37c5a960363b93af1a7fb4a3.file

The ostree repo is inside of the container image. It’s a extension on top of ostree: GitHub - ostreedev/ostree-rs-ext: Rust library with higher level APIs on top of the core ostree API

Right now, we’re pushing updates every day for Atomic Desktops, but ideally, we would release every week or two weeks like Fedora CoreOS. Once you move to this cadence, there is practically a guaranteed kernel update included. Thus investing a lot of effort in non-reboot updates is not really worth it. Non-reboot updates are for Flatpaks & containers.

For now the plan is to setup both the classic ostree repo and the new container format in parallel. Then we’ll have to figure out how to migrate users from one to the other.

4 Likes
13

The content of the container image may include things that are not part of an ostree commit (i.e. things added in a layer) but during the update on the system, everything is written back to the ostree repo and hardlinked.

Moving away from the hardlink-tree requires moving to composefs completely.

4 Likes
15

Yes, all the files under /usr are hardlinks to those under the repo in /sysroot/ostree/repo:

Thanks, I see they point to the same inode!
And, what about the rest of the directories under / ? Are these also indexed or not?
 

The ostree repo is inside of the container image. It’s a extension on top of ostree:

Interesting! This is totally new to me!
 

Right now, we’re pushing updates every day for Atomic Desktops, but ideally, we would release every week or two weeks like Fedora CoreOS. Once you move to this cadence, there is practically a guaranteed kernel update included. Thus investing a lot of effort in non-reboot updates is not really worth it. Non-reboot updates are for Flatpaks & containers.

I understand. So systemd soft reboot and rpm-ostree apply-live have little use?
 

For now the plan is to setup both the classic ostree repo and the new container format in parallel. Then we’ll have to figure out how to migrate users from one to the other.

So I guess, it will be the default in maybe Fedora 42?
 

Is there a document that describes the big vision about all of this? How it ideally all should work together? Or a plan that describes what is being worked on?
 

Thanks for your time!

16

I find rpm-ostree install --apply-live useful in Fedora CoreOS provisioning, when the app is not easy to containerize and making a custom image woud be too much.

1 Like
17

Only /usr.

rpm-ostree apply-live let’s you switch the content of /usr live. It comes with risks, similar to those encountered when updating packages live on a package based distribution. It’s useful for debugging and development. Only ever safe in additive cases (adding packages).

No commited timeline :slight_smile:. This is all very in-design/in-progress.

18

Only /usr.

Thanks, I see that almost everything is stored in either /usr or /var.
 

This reminds me of one last question I have (hopefully :wink: ):
I see Ostree is stored in /usr/bin. So that means, that Ostree updates itself when there is an Ostree update?

1 Like