[openstack-dev] [TripleO][Kolla] default docker storage backend for TripleO

Steven Dake (stdake) stdake at cisco.com
Thu May 18 03:29:27 UTC 2017

My experience with BTRFS has been flawless.  My experience with overlayfs is that occasionally (older centos kernels) returned ???????? as permissions (rather the drwxrwrw).  This most often happened after using the yum overlay driver.  I’ve found overlay to be pretty reliable as a “read-only” filesystem – eg just serving up container images, not persistent storage.

YMMV.  Overlayfs is the long-term filesystem of choice for the use case you outlined.  I’ve heard overlayfs has improved over the last year in terms of backport quality so maybe it is approaching ready.


From: Steve Baker <sbaker at redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Wednesday, May 17, 2017 at 7:30 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>, "dwalsh at redhat.com" <dwalsh at redhat.com>
Subject: Re: [openstack-dev] [TripleO][Kolla] default docker storage backend for TripleO

On Thu, May 18, 2017 at 12:38 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov<mailto:Kevin.Fox at pnnl.gov>> wrote:
I've only used btrfs and devicemapper on el7. btrfs has worked well. devicemapper ate may data on multiple occasions. Is redhat supporting overlay in the el7 kernels now?

overlay2 is documented as a Technology Preview graph driver in the Atomic Host 7.3.4 release notes:

From: Dan Prince [dprince at redhat.com<mailto:dprince at redhat.com>]
Sent: Wednesday, May 17, 2017 5:24 PM
To: openstack-dev
Subject: [openstack-dev] [TripleO][Kolla] default docker storage backend for    TripleO

TripleO currently uses the default "loopback" docker storage device.
This is not recommended for production (see 'docker info').

We've been poking around with docker storage backends in TripleO for
almost 2 months now here:


For TripleO there are a couple of considerations:

 - we intend to support in place upgrades from baremetal to containers

 - when doing in place upgrades re-partitioning disks is hard, if not
impossible. This makes using devicemapper hard.

 - we'd like to to use a docker storage backend that is production

 - our target OS is latest Centos/RHEL 7

As we approach pike 2 I'm keen to move towards a more production docker
storage backend. Is there consensus that 'overlay2' is a reasonable
approach to this? Or is it too early to use that with the combinations

Looking around at what is recommended in other projects it seems to be
a mix as well from devicemapper to btrfs.

[1] https://docs.openshift.com/container-platform/3.3/install_config/in
[2] http://git.openstack.org/cgit/openstack/kolla/tree/tools/setup_RedH

I'd love to be able to use overlay2. I've CCed Daniel Walsh with the hope we can get a general overview of the maturity of overlay2 on rhel/centos.

I tried using overlay2 recently to create an undercloud and hit an issue doing a "cp -a *" on deleted files. This was with kernel-3.10.0-514.16.1 and docker-1.12.6.

I want to get to the bottom of it so I'll reproduce and raise a bug as appropriate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170518/5ec25e32/attachment.html>

More information about the OpenStack-dev mailing list