Following up the discussion from the last containerd summit:
https://github.com/containerd/containerd/blob/6ae973362af4b9ae27fb335efba6b5e508bc1752/docs/dockercon-summit.md#discussion-points
How to support per-container fs quotas? The implementation of quotas (usually called project quotas) is tied to the specific implementation of the Snapshotter being used.
- What is the right abstraction to support different project quota implementations (
brtfs, overlay+xfs, overlay+ext4, and maybe in the future zfs, devicemapper and others since anyone can implement Snapshotter)?
- What is the right granularity for quotas? Some project quota implementations allow volumes and container writeable layers to be in the same quota group, and share the same quota limit. Is it something that need to be supported, or volumes will always be in different quota groups, managed completely outside containerd?
- During the discussion, encouraging read-only container filesystems was mentioned, and forcing people to use volumes for R/W directories, with quotas being managed by external volume managers. I agree this would be ideal, but is it even possible to force read-only rootfs for everyone?
Following up the discussion from the last containerd summit:
https://github.com/containerd/containerd/blob/6ae973362af4b9ae27fb335efba6b5e508bc1752/docs/dockercon-summit.md#discussion-points
How to support per-container fs quotas? The implementation of quotas (usually called project quotas) is tied to the specific implementation of the
Snapshotterbeing used.brtfs,overlay+xfs,overlay+ext4, and maybe in the futurezfs,devicemapperand others since anyone can implementSnapshotter)?