Re: ostree use cases and value

["Will Manley" <ostree williammanley net>]

Here's some random thoughts, may or may not be useful to you.

On Thu, 4 Nov 2021, at 18:45, Michael Brown wrote:

I am a designer for an embedded device and am investigating ostree. I have some questions that I have not been able to find answers for.

My device has an A/B partition update scheme currently (plus third data partition), and it's mandatory that the currently active partition be read-only at the flash/hardware level. I'm trying to understand what value, if any, we could get from moving that partition to ostree with a deployment created when we create the rootfs. If we do not make this partition writable, (ie. staying with squashfs), I'm not quite seeing obvious value in moving over to ostree. Is there something I'm missing?

Next, if we move to f2fs-on-loopback (we need compression, cant change underlying ext fs at this point), we still cant write to the system while it is running.

One option would be to have both A and B partitions have ostree installed. Then (when booted into A) you'd update the B partition using `chroot ostree admin update`.  Whether that would buy you anything on top of what you've already got depends on your current pain points. Ostree may be faster than writing a whole partition, or maybe re-using ostree's delta compression could be useful for you.

  - On development systems (which we have an existing process to cryptographically unlock), would like to be able to let developers install updated packages/files

We use ostree for this on our own (embedded) systems. Our build system spits out an ostree commit that is then deployed to our devices.  I've patched ostree so updating an existing deployment is O(changes) rather than O(files in rootfs).  This makes the dev on PC, deploy to device loop much faster - helpful for this use-case. See https://github.com/ostreedev/ostree/pull/1408 .

This is relatively quick, but still requires a reboot. I'd also planned to add updates in place for dev, but haven't got round to that yet.

To me, what seemed to make sense to solve for these would be something like:

  - best solution would be a way to have split repositories?

IIUC this is how flatpak works: the ostree repo for your rootfs and the repo for your flatpak applications are completely separate.

    - Is there a way to use symlinks for deployments?

I think deployments make sense for the rootfs, but I'm not sure that it could be applied to the applications. It would be fairly easy to implement yourself though: Checkout the new applcation under /apps/appname/SHA/ and afterwards update a /apps/appname/latest symlink to point at the version you want to use. This is the approach gobolinux takes, and maybe nix does too? I'm not sure.

    - is there a way to use overlayfs? Base-os as lowest layer, directory on the data partition as upper/work layers. Then deployments can be on the overlayfs.

      - solve use case for locked down system by only allowing base os daemons to run from deployment on the read only rootfs.

      - plugins can run from the overlayfs

      - if enabled, if there is an installed update for base os daemons, those can be run from the overlayfs.

`ostree admin unlock` sets up your rootfs with overlayfs.  It could be useful for dev use-cases, but probably not in production.  It's not something I've used myself as I always deploy new dev versions as ostree commits.

Is any of the above viable or are there better solutions?

Next, I was investigating flatpak, which looks like it's built on top of ostree. I'm thinking that (conceptually) we can take the base os on our device and have it set up as basically just systemd and dbus, and run all daemons out of separate application deployments. Is this straightforward to do with base ostree or does flatpak bring value here that we should be looking at?

I think much of what you're trying to achieve here is outside of the scope of ostree.  Ostree could be useful as a part of what you're trying to achieve. You could use it as part of your system like flatpak does as a mechanism for efficiently storing/transferring container images.  Ostree itself won't help much with understanding which applications to launch in what circumstance.

Regarding the idea of a minimal base system of systemd and dbus with applications built on top: I'd recommend looking at CoreOS. It's the same idea, but with docker containers.  They also use minimal A/B partitions for the base system with everything else installable as docker containers.

Thanks

Will