Re: [atomic-devel] Changing partitioning defaults discussion

[Colin Walters <walters verbum org>]

On Mon, Jun 5, 2017, at 01:58 PM, Dusty Mabe wrote:
> 
> One qualification - we use overlay2 by default, but we are going to be
> placing all of /var/lib/docker/ on its own filesystem:
> 
>     $ cat /etc/sysconfig/docker-storage-setup 
>     # Edit this file to override any configuration options specified in
>     # /usr/share/container-storage-setup/container-storage-setup.
>     #
>     # For more details refer to "man container-storage-setup"
>     STORAGE_DRIVER=overlay2
>     CONTAINER_ROOT_LV_NAME=docker-root-lv
>     CONTAINER_ROOT_LV_MOUNT_PATH=/var/lib/docker
>     GROWPART=true

Yes.  I think I'm proposing we keep that
behavior for F26, and change rawhide to remove the separate LV
by default.

(Hmm, a detail here is that because we frob GROWPART=true
 in the kickstart, ostree will from then on think it's user-modified
 and not take on new defaults =(   Will have to think about fixing that)

> One case this would affect is booting the qcow directly on kvm/libvirt
> without extending the disk image or adding another disk first.

Yes.  And while I'm sure people do that...I think in practice
that use case should go into one of:

 - ISO install into VM ("pet"/"elephant" machines)
 - vagrant (transient dev/test environments)

(Of course one can the ISO for dev/test and vagrant for pet/elephant machines
too but talking about the "defaults" of the tools here)

> If the default was to just put overlayfs on the root filesystem then i
> think this would work fine. If not, then we are basically forcing the
> vagrant user to add another disk for container storage. 

Yeah, in fact let me break this out as a sub-proposal - the Vagrant
box for F26 changes to "one big /".

> Am i correct in my assumption that the patch below only affects ISO
> installs that don't use a kickstart and just use the defaults?

Not quite; it also affects kickstart users that use `autopart`.

> > +    defaultFS = "xfs"
> 
> Not used anywhere that I can see

I think this is sucked into the blivet layer - so if the user is choosing
filesystems interactively in the GUI, that's what it'll use for example.
I bet it also comes back to us as `storage.default_fstype`.


> Could this be removed in a separate commit to explain why it is being
> removed?

Broadly we're matching Server.  You're correct to call this out though -
it will change to the new Fedora default of 1G (which to me feels
really excessive but we're not yet changing the cloud environment)