Red Hat Bugzilla – Bug 1475626
Change the default storage driver to overlay2
Last modified: 2018-02-27 17:05:36 EST
Description of problem:
Atomic Host currently defaults to devicemapper as the storage driver for docker. This needs to change to overlay2.
Version-Release number of selected component (if applicable):
So one thing I need to understand here - are we going to change what `docker` does by default for 7.5 or not? @rhvgoyal said to me something of the form "let's do kernel version checks"? Would we have something like
Alternatively of course we could just have separate 7.4 and 7.5 builds of docker, and anyone who does `yum update` on Extras without doing Server too is just broken?
We had a long chat about this on IRC; one foundational question here - is it PM's intention that this change *also* happens for yum-based RHEL? I'm assuming it is.
<vgoyal> walters: I think there is a problem there too. People might have assumed that default graph driver is devicemapper and specified put in other variables which are devicemapper specific.
<vgoyal> walters: so we will have to make sure that there are no devicemapper specific knobs in /etc/sysconfig/docker-storage-setup before we decide to switch to overlay2
<vgoyal> walters: also we might break a system which assumes that devicemapper is default. Over upgrade to css, they might suddenly see overlay2 as default.
Sorry I missed your question here. Yes, both RHEL & AH should be consistent with the defaults. I think it's best for new installs (yum & rpm-ostree) to default to overlay2, but for upgraded systems to continue as they were already configured (dm or whatever). After reading the PR, it seems like you guys came to the same conclusion.
Broke this for Atomic Host, because this runs on the *build* server side, and that introduces a dependency on the host filesystem type.
So...one idea is instead of doing this in docker's `%posttrans`, we do it on startup of container-storage-setup.
@vivek: Any reason you can think of that wouldn't work.
See also https://code.engineering.redhat.com/gerrit/#/c/127456/2 for the kickstart side.
(In reply to Colin Walters from comment #10)
> Broke this for Atomic Host, because this runs on the *build* server side,
> and that introduces a dependency on the host filesystem type.
> So...one idea is instead of doing this in docker's `%posttrans`, we do it on
> startup of container-storage-setup.
> @vivek: Any reason you can think of that wouldn't work.
We already do this check in container-storage-setup. Not sure why frantisek introduced it in spec file.
Author: Vivek Goyal <firstname.lastname@example.org>
Date: Mon Nov 13 13:59:15 2017 -0500
Check ftype=1 for xfs filesystem
One advantage of doing this check in spec file is that we choose right default to begin with and docker does not fail. If container-storage-setup detects it, then it will fail and docker with either fall back to loop back devices or fail (depending on whether docker.service has Wants= or Requires= dependency).
Can you elaborate a little more that how did it fail? I am not sure I understand the reason of failure.
So if we don't hear a rationale from fkluknav soon my proposal is that we just revert that change.
Agreed. This probably will not work for atomic build. I guess limitation is that atomic build server need to have xfs rootfs with ftype=1 and that might not be the case.
Frantisek, Why do we need this patch? Can we revert it to make sure atomic image generation is not broken.
Modifying config files in %posttrans feels slightly wrong-ish. Modifying it twice, in %posttrans and then at the first start of container-storage-setup, is needlessly confusing. Users who upgrade 7.4 -> 7.5 with ftype=0 will curse a lot. But if it must be, ok, so be it.