Bug 1475626 - Change the default storage driver to overlay2
Change the default storage driver to overlay2
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: container-storage-setup (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Frantisek Kluknavsky
: Extras
Depends On: 1505621
Blocks: 1477926
  Show dependency treegraph
Reported: 2017-07-26 23:06 EDT by Ben Breard
Modified: 2018-02-27 17:05 EST (History)
11 users (show)

See Also:
Fixed In Version: container-storage-setup-0.9.0-1.rhel75.gite0997c3.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1505621 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Github https://github.com/projectatomic/container-storage-setup/pull/262 None None None 2017-11-02 16:17 EDT

  None (edit)
Description Ben Breard 2017-07-26 23:06:39 EDT
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):


Additional info:
Comment 3 Colin Walters 2017-11-02 13:23:18 EDT
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

Comment 4 Colin Walters 2017-11-02 13:24:39 EDT
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?
Comment 5 Colin Walters 2017-11-02 14:17:13 EDT
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.
Comment 7 Ben Breard 2017-11-13 12:25:37 EST

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.
Comment 10 Colin Walters 2018-01-11 15:58:21 EST
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.
Comment 11 Colin Walters 2018-01-11 16:45:54 EST
See also https://code.engineering.redhat.com/gerrit/#/c/127456/2 for the kickstart side.
Comment 12 Vivek Goyal 2018-01-12 08:43:26 EST
(In reply to Colin Walters from comment #10)
> http://pkgs.devel.redhat.com/cgit/rpms/docker/commit/?h=extras-rhel-7.
> 5&id=8e8beddbf87d3b44410dbf05f23d743a3213800e]
> 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.

commit 7fffea78b4195bdb883c3dada90d11d140a2c60a
Author: Vivek Goyal <vgoyal@redhat.com>
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.
Comment 13 Colin Walters 2018-01-12 08:57:45 EST
So if we don't hear a rationale from fkluknav soon my proposal is that we just revert that change.
Comment 14 Vivek Goyal 2018-01-12 09:45:08 EST
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.
Comment 19 Frantisek Kluknavsky 2018-02-19 09:49:24 EST
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.

Note You need to log in before you can comment on or make changes to this bug.