This is an issue to track / follow up on a call re: file-level image distribution through remote filesystems.

Slides for CERN use-case shown during meeting: https://docs.google.com/presentation/d/1DJlRV9a445567EyRa265uemWv5zoDQ4o1CK-ZszpFLE/edit?usp=sharing

The goal is to support exploiting the existence of unpacked layers on remote filesystems (FUSE mounted, possibly read-only) to reduce the amount of data transferred during image pull. A candidate filesystem could be CVMFS (CERN VM Filesystem: https://github.com/cvmfs/cvmfs)

The current approach in containerd has an ordering where

1. all content is fetched and locally available via tarballs
2. layer tarballs are unpacked using and integrated via the snapshotter

which may be reversed such that

1. an unpack is attempted, possibly via access to remote fs, and if fails
2. the layer data is downloaded

Open Question:

• to what extent does the layer order matter when deciding for which layers the data download may be skipped. Ideally, a generic solution would be desirable, where the decision may be made independently for each layer, regardless of how its parent layers were acquired.
• can a single "remote fs" snapshotter suffice and the details be handled using configuration or does each remote fs need its own snapshotter -- tentative plan to start with one implementation and go from there

Related Issues and PRs:

#2267
#2697
#2391
#2467

Tagging the people present in the discussion: @dmcgowan @Random-Liu @rochaporto @jblomer @estesp @fuweid @crosbymichael @mikebrow @clelange @afortiorama