samuelkarp
commented
5 months ago I think this is useful and relevant commentary, but likely more in scope for the image (and associated image spec) than the runtime (the runtime spec assumes effectively a chroot-like projected/materialized structure rather than covering anything with tarballs or whiteouts).
In practice, a higher-level runtime manager (such as containerd, crio, or Docker) will be responsible for processing an image and preparing a bundle for the lower-level OCI runtime (such as runc or crun on Linux, or runj on FreeBSD). That may include flattening layers (the "native" snapshotter in containerd does this) or implementing copy-on-write to provide for storage deduplication and better speed in starting new containers (containerd uses overlay by default on Linux, but can also do this via ZFS snapshots on FreeBSD).
The image spec describes an interchange format currently based on tarballs and a JSON-formatted manifest file. But there are certainly shortcomings related to that (tar file ordering influences the digest and affects content-addressibility for the same content, for example). You can find some prior discussion of other proposals on the dev@opencontainers.org list.
But yes: if you have comments on ZFS images and how they could be used with containerd, please share!
I was just made aware that feedback is being collected on user stories in the requirements section. If so, would that include things like image/zfs-related topics or is that too implementation-specific and/or not within scope for the runtime environment? One of the things that I've noted down for myself is that images, as they are currently, are pretty tarball-centric (e.g. whiteout files) and not very friendly to ZFS images (e.g. full base image + incremental snapshots). Also, things like ZFS properties to hold metadata (instead of needing another manifest file).
I'm sure there's more that I can think of, but would like to know what the expected commentary should be restricted to in order to be useful.