Is it OK to promote the zfs root filesystem of a container, or could it confuse Incus?
I just tried it and when I deleted the “demoted” image, Incus deleted the image completely. There was no filesystem left behind in deleted/images. So it seems to work fine.
zfs-promote reverses the dependency of two filesystems:
If container a1 was launched from image a, then
{incus}/containers/a1 is a clone of {incus}/images/{a-fingerprint}@readonly
if I promote {incus}/containers/a1, then the dependency is reversed, and {incus}/images/{a-fingerprint} becomes a clone of {incus}/containers/a1@readonly.
The end result is that the container is no longer dependent on the image, and the image filesystem can be deleted cleanly.
I have come up with two use-cases for this:
-
Using an image to backup or transfer a container. Specifically, migrate one container at a time from LXD to Incus: Publish a snapshot of the container from LXD to an image, and export it. Then import it to another Incus system and launch a container from it. The new container is effectively the same as the old container, migrated from LXD to Incus. If I now promote the new container filesystem, I can delete the intermediate image. If I do not promote the new container’s filesystem, then the intermediate image stays around forever, possibly containing stale and sensitive data from the container (such as ssh keys, old database contents, etc.). This answers an old question of mine about how to use images to backup or transfer containers, also discussed here.
-
Launch a container from an image in order to attach the image filesystem to other containers. Specifically, I launch an alpine container from images:alpine/edge, install the latest Go package in it, make a snapshot, clone the snapshot to another zfs filesystem, and create a profile with a disk device of this filesystem. Then attach this profile to several other alpine containers. This way, I make available the latest Go compiler to several containers, without having to install it to each container separately. Besides saving space and bandwidth, this ensures that I get the edge version of Go, on non-edge alpine containers. I don’t use the original edge container again, but it stays around, along with its edge image. If I promote the cloned filesystem, then I can delete both the edge container and its image, so they do not clutter my installation. I do this because Go does not provide a tar file that can run on alpine, but alpine/edge typically has the latest version of Go within days of its release. In this example, I need to promote the container filesystem twice. Once for reversing the container-clone dependency, and a second time to reverse the image-container dependency.