roadmap

[lukasheinrich]

Hi @giuseppe ,

I found this repo through the singularity thread https://github.com/singularityware/singularity/issues/1207 and wanted to understand a bit more the status of this implementation. is there already a PoC of this working with a container runtime like podman or is that still far in the future?

Most of the infrastructure we use at CERN and elsewhere is based on RHEL so the ubuntu patches are not in play for us -- so this is very interesting to us

[giuseppe]

hi, I think this is already in a better shape than a PoC, I've used it for a while and could not see any major issue while working with different containers, or building them with Buildah. We are currently looking into packaging it so that it can be used from Fedora without requiring to build it.

We have integrated the https://github.com/amir73il/unionmount-testsuite testsuite, that is the same one used by overlay in the kernel.

Differently than the ubuntu patches that open overlay to unprivileged users, everything with fuse-overlay runs in userspace without any need of root privileges.

To be really usable from Podman/Buildah, we need Linux 4.18 that will allow FUSE from an user namespace. On older kernels you can still use it (I've not really tried though) and let podman point to it with --rootfs.

If you'd like to play with it, you can try on Rawhide where the Linux 4.18 is present and you can do as unprivileged user something like:

console podman --storage-driver overlay --storage-opt overlay.fuse_program=/usr/bin/fuse-overlayfs ... and that will internally use this implementation of overlayfs to setup the storage for the container.

/cc @rhatdan

[lukasheinrich]

Thanks that is very useful. I'll probably try this out once 4.18 gets released and fuse-overlayfs gets packaged --looking forward to it.

[giuseppe]

another feature is IDs shifting so that is not required to create another image with remapped uids when you work with usernamespaces: https://github.com/containers/storage/pull/195

That feature is probably useful also for root containers using usernamespaces. Especially for short lived once where the benefit of quickly creating the container is more important than the overlay-in-the-kernel performance.