Re: [meta-virtualization][PATCH] fuse-overlayfs-snapshotter: add recipe

[Bruce Ashfield <bruce.ashfield@gmail.com>]

Hi Thomas,

Reviewed the patch and it looks really good. I appreciate it
following the layer conventions with the go-mod-vcs hybrid layout
and the associated generated files.

One thing to resolve before I take it: the hardcoded /mnt/data
reference in two places.

  files/containerd-fuse-overlayfs.service:
    ExecStart=/usr/bin/containerd-fuse-overlayfs-grpc \
        /run/containerd-fuse-overlayfs/containerd-fuse-overlayfs.sock \
        /mnt/data/containerd-fuse-overlayfs

  fuse-overlayfs-snapshotter_git.bb do_install:
    echo "d /mnt/data/containerd-fuse-overlayfs 0700 root root - -" \
        > ${D}${sysconfdir}/tmpfiles.d/containerd-fuse-overlayfs.conf

/mnt/data isn't a path that will exist on a stock meta-virt image.
Was that intentional for your project (data partition mount
convention, etc.), or a holdover from a local test setup? FHS-normal
for a daemon's persistent store would be /var/lib/containerd-fuse-
overlayfs/ -- which also matches what the upstream project README
suggests when running out-of-box.

If /mnt/data is specific to your deployment and you need it, the
usual pattern in meta-virt is a recipe variable with a sane default:

    CONTAINERD_FUSE_OVERLAYFS_ROOT ?= "/var/lib/containerd-fuse-overlayfs"

referenced from both the service file (via a substitution during
do_install) and the tmpfiles.d entry. Downstreams that need /mnt/data
override the variable in their local.conf without carrying a bbappend.

A v2 switching the default to /var/lib/containerd-fuse-overlayfs and
(optionally) parameterizing via the above variable would be the
smallest change to get it into the tree. I'm happy to do the
amend on apply if you'd prefer to not spin another patch -- let me
know which you'd rather.

Cheers,

Bruce