Problem

Today containerd does not do any explicit mount lifecycle management, deferring management to shims and temp mount logic. The shims today perform mounts into its bundle rootfs directory, but have limitations in what kind of mounts they can perform as well as the ability to atomically clean up the bundle directory when those mounts are busy. Since the shim API has stabilized, adding new requirements to either handle new types of mounts or perform the mount operation differently would lead to backwards compatibility issues with the growing runtime shim community. Likewise, since shims still own the mounts, shims are limited in their ability to clean up quickly and atomically. The containerd daemon will also perform temporary mounts for some operations, however, failure to unmount can still make tracking resources complicated and requires a cleanup process.

Additionally, volume mounts or resources needed to perform mounts end up getting handled by plugins which are not involved in the container lifecycle. This can lead to unnecessary resource utilization or bloat of a plugin to keep unused resources available.

Use-Cases

• Chain mounts: An array of mounts where the target from a previous mount is used in a later mount. For example, mount a read only block device then mount an overlay with a writable upper layer.
• Device activation: Some mounts require devices which need explicit activation or a separate process to run. These devices should also go away after unmounted. For example:
  • Device mapper require device activation before mount
  • NBD and iSCSI need the local block device setup
  • TCMU would need either a call out to a plugin or start a process to create the device
  • Loopback setup for cases when the loop option isn't ideal
• Fuse: Setting up a fuse filesystem requires a plugin or external process to activate
• Overriding mount types: Cases where a plugin might want to handle a mount type differently than the system might or implement a mount type which isn't supported on the local system. For example, custom bind mount handling
• Creating new mount types: A plugin may want to define its own mount type, such as for the device activation or logging into block providing services.

Solution Overview

• Track mounts as a garbage collected resource
• Add support for custom mount handler
• Add manager interface for performing mounts but allowing system mounts to be passed through