Remove deprecated devicemapper storage driver #43637
Conversation
|
LGTM but maybe devicemapper can be discussed in a separate PR? containerd had once excluded devicemapper but added devicemapper later due to a request from the community of VM-based runtimes. |
|
Discussing in the maintainers meeting (specifically: @tianon @neersighted @corhere @tonistiigi @cpuguy83), there's some consensus that with the imminent containerd migration plans (cc @chris-crone), we should probably put a pause on completely removing these until that's done such that we keep coverage of the use cases for these other graph drivers (even if there won't be an explicit migration path). |
c958bb5 to
5bf7447
Compare
|
Given that AuFS has been deprecated both in docker and containerd, perhaps we should move that one separate? |
9096d6e to
adb02a9
Compare
I opened #45342 with only the first commit |
adb02a9 to
4758e99
Compare
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
4758e99 to
c33b311
Compare
| // isDeprecated checks if a storage-driver is marked "deprecated" | ||
| func isDeprecated(name string) bool { | ||
| switch name { | ||
| // NOTE: when deprecating a driver, update daemon.fillDriverInfo() accordingly | ||
| case "devicemapper": | ||
| return true | ||
| } | ||
| return false | ||
| } |
There was a problem hiding this comment.
It's an orthogonal discussion, but a use case for keeping this function: can we deprecate the zfs driver? (does overlay2 on top of ZFS work "ok" now?)
I guess we'll have to come up with a better generic "graph driver" deprecation message once we're ready to go all-in on the containerd migration, so maybe worth ignoring this thought and just letting this PR ride as-is.
There was a problem hiding this comment.
overlay2 will work on top of ZFS in the next release of ZFS, but at the moment there are no ZFS releases with the necessary support for overlayfs.
There was a problem hiding this comment.
overlay2will work on top of ZFS in the next release of ZFS, but at the moment there are no ZFS releases with the necessary support foroverlayfs.
I'm curious: what is/was the missing feature?
There was a problem hiding this comment.
@bra-fsn there's some discussion in #46337 (comment) related to overlayfs support on zfs
There was a problem hiding this comment.
@bra-fsn there's some discussion in #46337 (comment) related to overlayfs support on zfs
Thanks! So if the plan is to remove the ZFS driver at the end should it be safe to switch to ZFS+overlayfs (given I have the right ZFS version) now?
We have issues with it, sometimes destroying the FS fails with:
driver \"zfs\" failed to remove root filesystem: exit status 1: \"/usr/sbin/zfs destroy -r data/docker/c72f8a5f2af773735ad2ae5a96eebe6cf1593cf770d9475a1da1af76bd6d0cb6\" => cannot destroy 'data/docker/c72f8a5f2af773735ad2ae5a96eebe6cf1593cf770d9475a1da1af76bd6d0cb6': dataset is busy\n"
but ZFS is so effective for the docker workload with compression and deduplication (currently we have 6.87x dedup and 2x compression, that is huge) that switching away from it is a no-go.
There was a problem hiding this comment.
The very honest answer is that the usage of the zfs (and btrfs) drivers is marginal, and that they are a lot less "battle-tested" than overlay. We know there's some issues in both, and that some of the dependencies used in the implementation are poorly maintained (if at all). Contributions and fixes in those areas are definitely welcome, but with limited bandwidth/engineering time among maintainers for this project, work on these drivers is not on the top of the priority list. These drivers were originally contributed before overlay was a viable solution and to allow docker to run on other filesystems (zfs, btrffs), but our hope is for kernel support of overlay on zfs to mature so that overlay can be used in all situations (leaving zfs for expertise, "I know what I'm doing" use-cases).
We're also in the process of migrating to the containerd image-store, which provides native multi-arch support using containerd's snapshotters for storing images (whereas the graph-driver implementation only allows storing a single architecture for an image-tag). Graph-drivers will continued to be provided to help users transition, but will eventually go away. Containerd also has a snapshotter implementation for zfs (and btrfs), but I know the containerd maintainers are in a similar situation w.r.t. support for it (low amount of use, and poorly maintained dependencies), so they're also evalutating their future.
|
IMO, the containerd migration is sufficiently advanced now that I withdraw my earlier hesitation and personally think this PR is good-to-go. |
Mostly doing a quick inventory to see what can be removed; See individual commits for details
Relates to;
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)