Re: Modifying container storage for Fedora 26.

[Daniel J Walsh <dwalsh@xxxxxxxxxx>]

No as long as the storage is modified before the first start of the docker daemon and the first execution of docker-storage-setup, it should be fine.

On 11/17/2016 07:54 PM, Subhendu Ghosh wrote:

Assuming cloud-init can also select the storage or is that too late in the process?

On Nov 16, 2016 15:58, "Vivek Goyal" <vgoyal@xxxxxxxxxx> wrote:

On Wed, Nov 16, 2016 at 03:19:06PM -0500, Stephen Gallagher wrote:
> On 11/16/2016 03:09 PM, Vivek Goyal wrote:
> > On Wed, Nov 16, 2016 at 03:01:06PM -0500, Stephen Gallagher wrote:
> >> On 11/16/2016 02:56 PM, Vivek Goyal wrote:
> >>> On Wed, Nov 16, 2016 at 02:49:25PM -0500, Stephen Gallagher wrote:
> >>>> On 11/16/2016 02:40 PM, Vivek Goyal wrote:
> >>>>> On Wed, Nov 16, 2016 at 02:32:46PM -0500, Daniel J Walsh wrote:
> >>>>>> We would like to change the docker container storage to default to
> >>>>>> Overlayfs2 in Fedora 26.  But we have a problem on Atomic Host and
> >>>>>> Fedora Server distributions.
> >>>>>>
> >>>>>>
> >>>>>> Currently docker-storage-setup defaults to devicemapper and is hard
> >>>>>> coded to setup a thinpool of 40% of remaining disk.  Otherwise it sets
> >>>>>> up loopback devices on the root file system.   Devicemapper is nice
> >>>>>> since it works with thinpools and can automatically expand the storage
> >>>>>> if the disk space is getting used up.
> >>>>>>
> >>>>>> Moving to Overlay, we can more easily use the root file system directly,
> >>>>>> which would be fine for Fedora Workstation.  We want to preserve the use
> >>>>>> of the remaining storage for Overlay on AH and Fedora Server,  since
> >>>>>> this would give a user flexibility to switch back to using devicemapper
> >>>>>> if they had problems with the Overlay driver.
> >>>>>
> >>>>> And being able to do so basically involves following.
> >>>>>
> >>>>> - docker-storage-setup creates a logical volume from free space
> >>>>> - Creates a filesystem on that logical volume
> >>>>> - Mounts that logical volume on the directory which docker is going to
> >>>>>   use.
> >>>>>
> >>>>>   mount /dev/docker-vg/foo /var/lib/docker/
> >>>>>
> >>>>> - Now when docker users overlay2 graph driver, all the images, containers
> >>>>>   and associated metadata will be stored outside the root filesystem and
> >>>>>   onto /dev/docker-vg/foo logical volume.
> >>>>>
> >>>>>> We can not as easily
> >>>>>> support the expanding disk for Overlay since we will not use using thinpool.
> >>>>>
> >>>>>>
> >>>>>> We have looked at options to hard code OverlayFS with the defaults,
> >>>>>
> >>>>> If we always mount /var/lib/docker on on /dev/vg/foo for overlay2 driver
> >>>>> this will be a regression w.r.t current behavior. So I would not
> >>>>> recommend changing current behavior. I think this should be an opt-in.
> >>>>> We are working on provide a config knob to elect this behavior and
> >>>>> atomic host and fedora server will have to opt-in somehow.
> >>>>>
> >>>>> I think it will be easy for atomic host as they already drop something
> >>>>> in /etc/sysconfig/docker-storage-setup. Not sure how fedora server
> >>>>> variant will do it.
> >>>>>
> >>>>
> >>>>
> >>>> Today, Fedora Server relies on whatever is the default for docker-storage-setup.
> >>>> We just tell Anaconda to reserve up to 15GiB by default for the / partition and
> >>>> then it puts all remaining free space (on drives selected to be used by
> >>>> Anaconda) into a single logical volume with no partitions.
> >>>>
> >>>> It's a very easy thing for us to drop a different config file for
> >>>> docker-storage-setup into place for Server. So if that's all we need to do, let
> >>>> me know and I'll work it up.
> >>>
> >>> Ok, that sounds good. We are working on providing a knob to opt-in new
> >>> behavior. I think all you have to drop in config file will be something
> >>> like.
> >>>
> >>> /etc/sysconfig/docker-storage-setup
> >>>
> >>> STORAGE_DRIVER=overlay2
> >>> YET_TO_BE_NAMED_OPTION=VAL
> >>>
> >>> So upstream default will continue to be devicemapper. We will have to
> >>> modify fedora workstation, fedora server and atomic host infrastructure
> >>> to opt-in for overlay2.
> >>>
> >>
> >> Why exactly does this need to be opt-in? Why wouldn't we just change the default
> >> on Fedora Server to use overlay2 instead of devicemapper?
> >>
> >> I think I'm missing some key part of the problem here.
> >
> > I mean it will be devicemapper in upstream project. And distributions will
> > have to opt-in for overlay2.
> >
> > And I think one reason being that rhel uses same git tree and we don't
> > want to switch to overlay2 by default for rhel yet.
> >
> > overlay2 will be an experiment on fedora first as default and if it works
> > well, then change default upstream too.
>
> OK, when you said "opt-in", I was assuming you meant that from the user's
> perspective (as in having the user make an explicit choice). What you meant was
> that Server would carry a different default from the upstream project. That's
> easy enough to accomplish (we can do the same for Atomic as well).
>
> The packaging guidelines for this are here:
> https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration
>
> Of course, that's only necessary if we want Server (and Atomic) to differ from
> Workstation and/or non-productized Fedora. If they're all going to switch to
> overlay2, then it's just a trivial matter.

I think all are going to switch to overlay2 by default. But there will
be on difference. Fedora workstation will like to have its overaly2
setup on top of rootfs. While Fedora Server and Atomic Host will like
to carve out extra logical volume from free space and setup overlay2
on top of that.

So there will be total of two config options. One will be same in all
3 variants. While second one will be used only by server and atomic
host variants.

/me goes to read per product configuraiton link now.

Vivek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@lists.fedoraproject.org

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx