Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate "devicemapper" storage driver. #1424

Merged
merged 1 commit into from
Oct 17, 2018

Conversation

thaJeztah
Copy link
Member

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.

@codecov-io
Copy link

codecov-io commented Oct 9, 2018

Codecov Report

Merging #1424 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1424   +/-   ##
=======================================
  Coverage   54.19%   54.19%           
=======================================
  Files         289      289           
  Lines       19377    19377           
=======================================
  Hits        10502    10502           
  Misses       8199     8199           
  Partials      676      676

Copy link
Collaborator

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🐸

@AkihiroSuda
Copy link
Collaborator

Can we have WARNING: devicemapper is deprecated in docker info?

@AkihiroSuda
Copy link
Collaborator

Maybe we should have the warning message in daemon log?

@thaJeztah
Copy link
Member Author

Yes, having warnings both in logs and in docker info output is a good idea; I'll open PR's for those

@thaJeztah
Copy link
Member Author

ping @silvin-lubecki PTAL

Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@vdemeester
Copy link
Collaborator

@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 <github@gone.nl>
@thaJeztah thaJeztah merged commit 445df70 into docker:master Oct 17, 2018
@GordonTheTurtle GordonTheTurtle added this to the 19.03.0 milestone Oct 17, 2018
@thaJeztah thaJeztah deleted the deprecate_devicemapper branch October 17, 2018 16:15
@joshsleeper
Copy link

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, devicemapper and vfs are the only supported storage drivers for CentOS, unless that's out of date and overlay2 actually is supported?

image

@thaJeztah
Copy link
Member Author

@joshsleeper hm, looks like that table is quite out of date. Also not sure why vfs is listed under recommended storage drivers; it definitively isn't

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

@egernst
Copy link

egernst commented Nov 21, 2018

@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?

@thaJeztah
Copy link
Member Author

@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)

@egernst
Copy link

egernst commented Nov 21, 2018

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!

@gerroon
Copy link

gerroon commented Jan 15, 2019

Can you tell us how to migrate at least? Failed Docker after the upgrade is no use at all.

@cpuguy83
Copy link
Collaborator

Argh... I can't believe this didn't get fixed in 18.09.1...

@sarahn
Copy link

sarahn commented Apr 23, 2019

Can there be an approximate date for when devicemapper will be removed entirely?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.