[FEATURE] Support for podman

[iain-macdonald]

Description

Hi soci-snapshotter maintainers,

We would like to use the SOCI Snapshotter to reduce image pull time for containers running in our remote execution service at BuildBuddy. I’ve managed to get the snapshotter to work in our environment but it requires some modification because we use podman to pull and run container images in production. I’m curious if you would be open to merging a pull request adding support for podman to the snapshotter? It’s worth noting that such support already exists for the stargz-snapshotter on which the soci-snapshotter is based.

I have a forked repository with the changes to support podman at https://github.com/iain-macdonald/soci-snapshotter – the gist of these changes are to add a new binary, soci-store that mounts a fuse that uses the snapshotter to fetch image layers on demand. This is mostly self-contained but required a couple of other changes in the code, most notably exposing the layer-to-ztoc mapping in snapshot.go to the store so that it has that information.

There are a couple of things I still want to clean up in the forked repo, but I’m mostly just curious if you’re interested in accepting this or if we should plan on maintaining this fork.

Thanks for all of your hard work on this, it looks like it’s going to help us out quite a bit!
Iain

Describe the solution you'd like

No response

Describe any alternative solutions/features you've considered

No response

Any additional context or information about the feature request

No response

[Kern--]

Hey, cool! I'm glad you got it working, but I think podman support is out of scope for this specific project. Our core use-case is containerd (hence building around a containerd snapshotter) and we don't really have the experience with podman to properly maintain an integration. That said, I think there could be a lot of value in working to separate the core SOCI FS piece from the snapshotter implementation so that we can have separate integrations with various runtimes. I think that could be useful for sharing ideas between SOCI and stargz as well if they're interested.

In the short term, we would be willing to consider the patches you need that would allow you to consume SOCI as a library rather than requiring a fork so long as you're ok with unstable nature of our library APIs.

[iain-macdonald]

Thanks for the reply, Kern. If we'll still have to maintain a fork or patch on our side then refactoring the code as you describe isn't as high a priority for me. If I get around to it some time, I'll reach out again. In the mean time, I'll close this feature request. And if you change your mind, let me know!