[FEATURE] Split soci snapshotter into fuse and snapshotter processes #518
Labels
feature
New feature or request
tracking issue
Issue that doesn't get worked on directly but tracks overall effort of multiple related issues
Description
Today, the SOCI snapshotter process itself acts as both the snapshotter and the host process for the FUSE mountpoints used by each image layer. The major drawback of this approach is that if the snapshotter dies for any reason, then all running containers also die. A secondary drawback is that all containers are pulled in the network namespace that the snapshotter was launched in. With non-remote snapshotters, the pulling process can be launched in any network namespace which gives more control over what network resources any particular puller can access.
Describe the solution you'd like
It's worth investigating splitting the snapshotter into multiple processes:
There are several open questions that I can think of (and probably many more that would come up if we started looking). For, example:
Describe any alternative solutions/features you've considered
It's possible this is additional architectural complexity that isn't actually needed. It would be worth trying to gather community feedback on whether this is a real problem for people.
Any additional context or information about the feature request
The stargz community has been trying to implement a similar change for quite a while containerd/stargz-snapshotter#324
The text was updated successfully, but these errors were encountered: