Deprecate "devicemapper" storage driver. #1424
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1424 +/- ##
=======================================
Coverage 54.19% 54.19%
=======================================
Files 289 289
Lines 19377 19377
=======================================
Hits 10502 10502
Misses 8199 8199
Partials 676 676 |
thaJeztah
added
impact/changelog
impact/deprecation
status/3-docs-review
and removed
status/0-triage
labels
|
Can we have |
|
Maybe we should have the warning message in daemon log? |
|
Yes, having warnings both in logs and in |
|
ping @silvin-lubecki PTAL |
|
@thaJeztah needs a rebase 🙏 |
The `devicemapper` storage driver is deprecated in favor of `overlay2`, and will be removed in a future release. Users of the `devicemapper` storage driver are recommended to migrate to a different storage driver, such as `overlay2`, which is now the default storage driver. The `devicemapper` storage driver facilitates running Docker on older (3.x) kernels that have no support for other storage drivers (such as overlay2, or AUFS). Now that support for `overlay2` is added to all supported distros (as they are either on kernel 4.x, or have support for multiple lowerdirs backported), there is no reason to continue maintenance of the `devicemapper` storage driver. Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah
force-pushed
the
deprecate_devicemapper
branch
from
7eaf1c3
to
662441b
Compare
|
Sorry to necropost a bit, bit I haven't found any good documentation explaining how this doesn't negatively affect CentOS. At least according to the current docs,
|
|
@joshsleeper hm, looks like that table is quite out of date. Also not sure why overlay2 is supported on current versions of CentOS, Ubuntu, Debian, Fedora, and RHEL (but only Docker Enterprise ships for RHEL) I'll open a pull request to amend that page |
|
@thaJeztah - Obviously late to the party here, but as a developer on a VM-isolated container runtime (kata-containers), there is a lot of utility to having a block based storage solution available. AFAIU devicemapper is the only storage driver which provides this. Are there any functional / support issues with device-mapper today that's leading to the deprecation? |
|
@egernst I commented with some details on the roadmap in docker/for-linux#452 (comment), and also was discussing options with containerd maintainers. They informed me that they are open for contributions to implement and add a containerd snapshotter that provides block based storage. Wether or not this would be devicemapper would have to be looked at (there may be more performant choices). I think they actually recently had a conversation with contributors that were interested to work on this, but I don't have the details. Perhaps it would be good to open a tracking issue in the containerd issue tracker (if none exists yet) |
|
Thanks for the quick reply @thaJeztah - that thread covers it nicely. The need is for block-based, whether it be devicemapper or not isn't particularly important to us. I'll open an issue in containerd if none exists yet and continue the conversation there. Thanks! |
|
Can you tell us how to migrate at least? Failed Docker after the upgrade is no use at all. |
|
Argh... I can't believe this didn't get fixed in 18.09.1... |
|
Can there be an approximate date for when devicemapper will be removed entirely? |
The
devicemapperstorage driver is deprecated in favor ofoverlay2, and willbe removed in a future release. Users of the
devicemapperstorage driver arerecommended to migrate to a different storage driver, such as
overlay2, whichis now the default storage driver.
The
devicemapperstorage driver facilitates running Docker on older (3.x) kernelsthat have no support for other storage drivers (such as overlay2, or AUFS).
Now that support for
overlay2is added to all supported distros (as they areeither on kernel 4.x, or have support for multiple lowerdirs backported), there
is no reason to continue maintenance of the
devicemapperstorage driver.