inefficient updates for bootc on small board computers.

[phr34k]

The development experience with containers are really great, but I have questions or rather said reservations about using oci specification as a transport protocol and storage medium. To my understanding bootc uses ostree as an implementation detail, but it's not guaranteed that this will always remain in place. In certain aspects, I believe the transport mechanism of ostree seem to be better fit, so I'm left wondering how practical applying bootc is and what to expect from it.

To give some context, I work with small embedded devices, like the Raspberry PI with dedicated emmc storage. Due to the limited capacity, the storage often doesn't allow for a real a/b partitioning. Common scenario is that these devices might have a cellular data plan, to receive updates, so both storage usage and transport of updates should be efficient. In this area, it seems to me, it's still a bit immature and maybe just plain inefficient.

The project oci-delta suggests that the transport inefficiencies could be addressed, but the consumable device will require sufficient "transient" storage. Since storage is also limited, on first glace, the 'reference' oci-archive, the 'delta' oci-archive, and ostree commit on device is simply is not enough disk space for. Maybe for small updates it's fine, but maybe for a larger update i'm worried of cannot fulfill the constraints. With a traditional a/b update you know exactly you can split emmc, and with ostree you know your worst-case scenario will be a classical a/b update, but with oci-delta's you suddenly also need pull all of this transient storage from somewhere.

$ oci-delta create old.oci-archive new.oci-archive update.oci-delta

$ oci-delta apply update.oci-delta reconstructed.oci-archive
$ bootc switch --transport=oci-archive reconstructed.oci-archive
$ rm update.oci-delta reconstructed.oci-archive

I'm just wondering where small devices fit in the ecosystem, I think maybe these devices could/should have an option to use a more traditional central repository like ostree, something that could import bootc containers and serve them as regulair ostree commits for example.

[cgwalters]

The project oci-delta suggests that the transport inefficiencies could be addressed, but the consumable device will require sufficient "transient" storage.

The transient storage is only the size of the delta in the tar layers though.

Bigger picture though, I think oci-delta is going to be the best solution to what you're asking about so it's probably best to move this discussion there.

[phr34k]

If i look at the code example of oci-delta: it looks like you need compute the an oci archive before it can be handed/merged into ostree. So that means i need to keep an 'before.oci' ready on the device (in addition to the ostree commit itself). So if my 'before.oci' = 3gb and my 'delta.oci' is 1gb, means a minimum of 4gb of transient storage, which can then be hydrated into ostree storage. The project also mentions, that layers have to be re-compressed on the device.

So just as an thought excersize to emphasize the big picture, of course assuming worst-case scenario:

6gb of emmc
--------------------------
3gb of ostree commit
3gb of before.oci
1gb of delta.oci
4gb of after.oci

[djach7]

Hi @phr34k, thanks for bringing this up. Seconding what @cgwalters said, this sounds like more of an oci-delta conversation. I think the oci-delta import command might be a little more useful in your case than apply is, but please create an issue here to continue the discussion.