8️⃣ Here's the 8th post highlighting key new features of the upcoming v260 release of systemd. #systemd260 #systemd
In the 4th posting of this current series, we introduced the new .mstack/ directory type, for putting together service and container trees from stacks of overlayed directory trees and bind mounts, all in a self-descriptive directory.
In v260 there's also one major user of this new concept: the importctl tool gained a new "pull-oci" verb for downloading OCI containers. What it…
…actually does is talk to the OCI registry, find all the layers, download them and unpacks them into a .mstack/ directory, then converts the OCI metadata into a .nspawn file, and is done.
Or in other words, with this you can download any OCI container you like and then boot it with nspawn. Or in fact run it as a system service via RootMStack= in a unit file.
it's still a bit barebones, since the focus so far has been on acquiring the container trees and getting them into executable shape, but…
…not so much actually adding the glue for integrating this nicely into the OS, but this will come in one of the next releases, hopefully.
Oh, and all of this works unprivileged too, i.e. you can do "importctl --user pull-oci" to download a container image into your home directory.
@amackif
I've seen documentation of a former systemd integration of Podman containers into machinectl. Even an eventual systemd unit tree inside a Podman container would have been transparent to the host system.
Now Podman has an integration with systemd through Quadlets and sd_notify()
I would love to see tighter integration of OCI images with machinectl, esp. updates, tags + rootless.
Could the old integration find a return through these new, converging interfaces? Like Incus+OCI?
@pid_eins
Lennart Poettering
amackif
jon r